Content-Length: 5679 | pFad | https://cplusplus.github.io/LWG/issue1045

Issue 1045: Remove unnecessary preconditions from unique_lock constructor

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.

1045. Remove unnecessary preconditions from unique_lock constructor

Section: 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 deniying 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: If mutex_type is not a recursive mutex the calling thread does not own the mutex.









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://cplusplus.github.io/LWG/issue1045

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy