This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.

1489. unlock functions and unlock mutex requirements are inconsistent

Section: 32.6 [thread.mutex] Status: NAD Editorial Submitter: Switzerland Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.mutex].

View all issues with NAD Editorial status.

Discussion:

Addresses CH-26

Specifications of unlock member functions and unlock mutex requirements are inconsistent wrt to exceptions and pre- and postconditions.

[ Resolution proposed by ballot comment: ]

unlock should specifiy the precondition that the current thread "owns the lock", this will make calls without holding the locks "undefined behavior". unlock in [mutex.requirements] should either be noexcept(true) or be allowed to throw system_error like unique_lock::unlock, or the latter should be nothrow(true) and have the precondition owns == true. Furthermore unique_lock's postcondition is wrong in the case of a recursive mutex where owns might stay true, when it is not the last unlock needed to be called.

Proposed resolution: