980. mutex lock() missing error conditions

Section: 32.6.4 [thread.mutex.requirements] Status: NAD Submitter: Ion Gaztañaga Opened: 2009-02-07 Last modified: 2016-01-28

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.

Discussion:

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.

Consider:

//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.

1. For state_not_recoverable add it to the list of Error conditions:
2. For owner_dead, no proposed resolution.

[ Summit: ]

Not a defect. Handling these error conditions is an implementation detail and must be handled below the C++ interface.

Proposed resolution:

Add to 32.6.4 [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.
• state_not_recoverable -- if the state protected by the mutex is not recoverable.