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.
unlock
functions and unlock mutex requirements are inconsistentSection: 33.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 benoexcept(true)
or be allowed to throwsystem_error
likeunique_lock::unlock
, or the latter should benothrow(true)
and have the preconditionowns == true
. Furthermoreunique_lock
's postcondition is wrong in the case of a recursive mutex whereowns
might stay true, when it is not the lastunlock
needed to be called.
Proposed resolution: