Opened 6 years ago

Closed 5 years ago

#12731 closed Support Requests (obsolete)

boost::thread::join deadlock

Reported by: Antoine Poliakov <antoinep92@…> Owned by: viboes
Milestone: To Be Determined Component: thread
Version: Boost Development Trunk Severity: Problem
Keywords: thread interuption deadlock Cc:

Description

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.

Attachments (1)

main.cpp (991 bytes ) - added by Antoine Poliakov <antoinep92@…> 6 years ago.
minimal test case to reproduce (unix only!)

Download all attachments as: .zip

Change History (4)

by Antoine Poliakov <antoinep92@…>, 6 years ago

Attachment: main.cpp added

minimal test case to reproduce (unix only!)

comment:1 by viboes, 6 years ago

Owner: changed from Anthony Williams to viboes
Status: newassigned

As I understand the code, waiting on condition variables is a consequence of the interruptible nature to boost thread.

Could you tell us where the thread is blocked?

Any suggestion of for improving the code is welcome.

I believe that waiting for a fix, updating the documentation is a good thing to do. Please create a specific ticket for the documentation. A patch is welcome also here.

Last edited 6 years ago by viboes (previous) (diff)

comment:2 by viboes, 6 years ago

Type: BugsSupport Requests

Moved to Support request waiting for more information

comment:3 by viboes, 5 years ago

Resolution: obsolete
Status: assignedclosed

Closed as there is no follow up.

Note: See TracTickets for help on using tickets.