This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

2140. Meaning of notify_all_at_thread_exit synchronization requirement?

Section: 32.7 [thread.condition] Status: C++14 Submitter: Pete Becker Opened: 2012-03-06 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.condition].

View all issues with C++14 status.

Discussion:

notify_all_at_thread_exit has the following synchronization requirement:

Synchronization: The call to notify_all_at_thread_exit and the completion of the destructors for all the current thread's variables of thread storage duration synchronize with (6.9.2 [intro.multithread]) calls to functions waiting on cond.

The functions waiting on cond have already been called, otherwise they wouldn't be waiting. So how can a subsequent call to notify_all_at_thread_exit synchronize with them?

Also, "synchronizes with" is a relationship between library calls (6.9.2 [intro.multithread]/8), so it's not meaningful for completion of destructors for non-library objects. Presumably the intention wasn't so make library destructors special here.

[2012-03-09 Jeffrey Yasskin comments:]

I think the text should say that "notify_all_at_thread_exit and destructor calls are sequenced before the lk.unlock()", and leave it at that, unless there's a funny implementation I haven't thought of.

[2012-03-19 Hans Boehm comments:]

I think the synchronization clause should just be replaced with (modulo wording tweaks):

"The implied lk.unlock() call is sequenced after the destruction of all objects with thread storage duration associated with the current thread."

as Jeffrey suggested.

To use this correctly, the notifying thread has to essentially acquire the lock, set a variable indicating it's done, call notify_all_at_thread_exit(), while the waiting thread acquires the lock, and repeatedly waits on the cv until the variable is set, and then releases the lock. That ensures that we have the proper synchronizes with relationship as a result of the lock.

[2012, Portland: move to Review]

The lk.unlock() refers back to the wording the previous paragraph.

Moved to review

[2013-04-20, Bristol]

Accepted for the working paper

Proposed resolution:

This wording is relative to N3376.

1. Modify 32.7 [thread.condition] p8 as indicated:

   void notify_all_at_thread_exit(condition_variable& cond, unique_lock<mutex> lk);
   

   […]

   -8- Synchronization: The call to notify_all_at_thread_exit and the completion of the destructors for all the current thread's variables of thread storage duration synchronize with (6.9.2 [intro.multithread]) calls to functions waiting on cond The implied lk.unlock() call is sequenced after the destruction of all objects with thread storage duration associated with the current thread.