1489. unlock functions and unlock mutex requirements are inconsistent

Section: 33.4 [thread.mutex] Status: NAD Editorial Submitter: Switzerland Opened: 2010-08-25 Last modified: 2016-02-10

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: