Proposed resolution:

This wording is relative to N3376.

1. Modify [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 ([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.

[ 2013-04-20, Bristol ]

Accepted for the working paper

[ 2012, Portland: move to Review ]

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

Moved to review

[ 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-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.

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 ([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 ([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.