id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
7319	Take care of c++std-lib-32966 issue	viboes	viboes	"Take care of the issue raised by Howard Hinnant in 

[c++std-lib-32966] Public service announcement concerning ~condition_variable_any()

""Both condition_variable and condition_variable_any are based on the POSIX pthread_cond_t.  One of the very subtle behaviors of pthread_cond_t is that it is ok for a pthread_cond_t to be destroyed after all waiting threads have been signaled (assuming no new threads initiate a wait).  There's even an example demonstrating this at http://www.unix.org/online.html under the specification for pthread_cond_destroy.

This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any:

> Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait must happen before destruction. The user must take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate. — end note ]

To be *perfectly* clear, the following is ok:


{{{
  Thread A                    Thread B
   ...                        lk.lock()
   ...                        cv.wait(lk)
  lk.lock()                      ...
  cv.notify_one()                ...
  cv.~condition_variable_any()   ...
  lk.unlock()                    ...
    ...                       finally exits cv.wait  // ok, not a data race
}}}

""



"	Bugs	assigned	To Be Determined	thread	Boost 1.51.0	Problem