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
 post-conditions.
 >
 > 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
 one.

 > > - 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: <https://svn.boost.org/trac/boost/ticket/7669#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.