This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
unique_lock constructorSection: 32.6.5.4.2 [thread.lock.unique.cons] Status: C++11 Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [thread.lock.unique.cons].
View all issues with C++11 status.
Discussion:
Addresses UK 326 [CD1]
The precondition that the mutex is not owned by this thread offers introduces the risk of unnecessary undefined behaviour into the program. The only time it matters whether the current thread owns the mutex is in the lock operation, and that will happen subsequent to construction in this case. The lock operation has the identical pre-condition, so there is nothing gained by asserting that precondition earlier and denying the program the right to get into a valid state before calling lock.
[ Summit: ]
Agree, move to review.
[ Batavia (2009-05): ]
We agree with the proposed resolution. Move to Tentatively Ready.
Proposed resolution:
Strike 32.6.5.4.2 [thread.lock.unique.cons] p7:
unique_lock(mutex_type& m, defer_lock_t);
-7- Precondition: Ifmutex_typeis not a recursive mutex the calling thread does not own the mutex.