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: 33.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 33.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.