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.5 [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: