Re: [Boost-bugs] [Boost C++ Libraries] #7669: thread_group::join_all() should catch resource_deadlock_would_occur

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7669: thread_group::join_all() should catch resource_deadlock_would_occur
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-11-10 21:04:38

#7669: thread_group::join_all() should catch resource_deadlock_would_occur
  Reporter: boost.lists@… | Owner: anthonyw
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: thread
   Version: Boost 1.52.0 | Severity: Problem
Resolution: | Keywords: thread;thread_group

Comment (by viboes):

 Replying to [comment:4 Igor R. <boost.lists@…>]:
> Replying to [comment:3 viboes]:
> First of all, the question is whether we want to improve thread_group
 and make it more usable - or not. If you really intend to deprecate it,
 then perhaps changing the formal pre-condition is enough.

 Ye sthis is my intention, but I need movable containers more portables.
 There are yet some compilers in the regression tests that don't support
 Boost.Move,/Container, ...

> On the other hand, if the intent is to improve the usability, I'am
 afraid none of the 2 options would really help.
> > You are right, the user can not check this pre-condition as it has no
 access to the threads in the group other than duplicating. But calling to
 join_all and joining all but one of the threads don't respect either the
> Right, the post-condition should be updated, if you decide to handle
 this_thread case. But please note that thread::join() post-condition is
 also incorrect with regard to this issue.

 Please, could you say explicitly what is incorrect?

> IIUC, this story began when thread::join() just deadlocked if it was
 this_thread, and thread & thread_group behaved consistently at this point;
 then the deadlock issue was solved by throwing
 resource_deadlock_would_occur exception, but neither formal post-condition
 of thread::join() nor thread_group behavior were updated.

 You know more than me.

> > I don't think it is a good design to to request to join on itself.
> Usually it's not a deliberate decision to join on itself, but design
 constraints, when trying to avoid this situation might unnecessarily
 complicate design. But "bad design" argument is even more applicable to
 thread::join() itself - nevertheless its behavior is reasonable and
 doesn't produce UB.

 Could you give an example where the user could want to call join_all from
 a thread inside the thread_group. I don't see none. In addition, it is
 difficult to provide a consistent behavior if this case could be a valid

> > - the implementation check always if the this_thread is in the thread
 group and throw a specific exception
> What should the user do at this point? IIUC, it's impossible to recover
 from this situation (as opposed to thread::join() case!).

 You are right. this is not a solution.

> > - the library provides a function that states if this_thread is in the
 thread group, so that the user that is in a context that the current
 thread could be one of the group could check it. The join_all function has
 the Require clause described above.
> Actually, this's equivalent to the above option, i.e the user will get
 information but won't be able to recover.

 Not really. Note that this is an exception throw to signal a pre-condition
 not satisfied situation? The user needs of course change his design.

> P.S. please note that this ticket doesn't differ much from #7668.

 Yes, and join() has as pre-condition that a thread can not join itself. I
 was just extrapolating the same argument on the second solution I gave.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:11 UTC