[Boost-bugs] [Boost C++ Libraries] #12731: boost::thread::join deadlock

Subject: [Boost-bugs] [Boost C++ Libraries] #12731: boost::thread::join deadlock
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2017-01-06 14:54:06

#12731: boost::thread::join deadlock
 Reporter: Antoine Poliakov <antoinep92@…> | Owner: anthonyw
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: thread
  Version: Boost Development Trunk | Severity: Problem
 Keywords: thread interuption deadlock |
 I just hit a deadlock while `join()`ing a `boost::thread`, meaning the
 `join()` is blocked for ever. I did this by `pthread_cancel()`ing the
 thread (using `native_handle()`) and then waiting for it to actually
 terminate using `join()`.

 See the attached minimal case.

 Boost's `join()` never returns, while `pthread_join(native_handle())`
 works as expected. Looking at the code here
 https://github.com/boostorg/thread/blob/develop/src/pthread/thread.cpp I
 notice that `join_noexcept()` actually waits on condition variables before
 calling `pthread_join`.

 I believe this is a design flaw, as there are many dirty/low-level ways to
 stop a thread (e.g. signals or OS threading API), and there is no way to
 keep the `boost::thread` state in sync with the thread state in these
 cases of non-standard termination.

 I think we should be only relying on the OS API here, to query the thread
 state (running, joinable, etc.) instead of storing flags that may run out
 of sync. Alternatively, the documentation should be updated with a
 prominent warning saying that `boost::thread` has undefined behavior if a
 thread is stopped in a non standard way and `native_handle` should be used
 with care.

 Note that at least libstdc++ does not exbibit the same problem.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/12731>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

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