This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 30.4.3 [thread.mutex.requirements] Status: NAD Submitter: Ion Gaztañaga Opened: 2009-02-07 Last modified: 2016-02-10
Priority: Not Prioritized
View other active issues in [thread.mutex.requirements].
View all other issues in [thread.mutex.requirements].
View all issues with NAD status.
POSIX 2008 adds two return values for pthread_mutex_xxxlock(): EOWNERDEAD (owner_dead) and ENOTRECOVERABLE (state_not_recoverable). In the first case the mutex is locked, in the second case the mutex is not locked.
Throwing an exception in the first case can be incompatible with the use of Locks, since the Lock::owns_lock() will be false when the lock is being destroyed.
//Suppose mutex.lock() throws "owner_dead" unique_lock ul(&mutex); //mutex left locked if "owner_dead" is thrown
Throwing an exception with owner_dead might be also undesirable if robust-mutex support is added to C++ and the user has the equivalent of pthread_mutex_consistent() to notify the user has fixed the corrupted data and the mutex state should be marked consistent.
[ Summit: ]
Not a defect. Handling these error conditions is an implementation detail and must be handled below the C++ interface.
Add to 30.4.3 [thread.mutex.requirements], p12:
-12- Error conditions:
- operation_not_permitted -- if the thread does not have the necessary permission to change the state of the mutex.
- resource_deadlock_would_occur -- if the current thread already owns the mutex and is able to detect it.
- device_or_resource_busy -- if the mutex is already locked and blocking is not possible.