unlock functions and unlock mutex requirements are inconsistentSection: 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: ]
unlockshould specifiy the precondition that the current thread "owns the lock", this will make calls without holding the locks "undefined behavior".unlockin [mutex.requirements] should either benoexcept(true)or be allowed to throwsystem_errorlikeunique_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 whereownsmight stay true, when it is not the lastunlockneeded to be called.
Proposed resolution: