Proposed resolution:

This wording is relative to N4527.

1. Change [thread.mutex.requirements.mutex] as indicated:

   […]

   -4- The error conditions for error codes, if any, reported by member functions of the mutex types shall be:

   1. (4.1) — resource_unavailable_try_again — if any native handle type manipulated is not available.

   2. (4.2) — operation_not_permitted — if the thread does not have the privilege to perform the operation.

   3. (4.3) — device_or_resource_busy — if any native handle type manipulated is already locked.

   […]

   -13- Error conditions:

   1. (13.1) — operation_not_permitted — if the thread does not have the privilege to perform the operation.

   2. (13.2) — resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.

   3. (13.3) — device_or_resource_busy — if the mutex is already locked and blocking is not possible.

2. Change [thread.sharedmutex.requirements] as indicated:

   […]

   -10- Error conditions:

   1. (10.1) — operation_not_permitted — if the thread does not have the privilege to perform the operation.

   2. (10.2) — resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.

   3. (10.3) — device_or_resource_busy — if the mutex is already locked and blocking is not possible.

   […]

[ 2015-10 Kona ]

Geoffrey provides new wording.

Previous resolution [SUPERSEDED]:

This wording is relative to N3936.

1. Change [thread.mutex.requirements.mutex] as indicated:

   -13- Error conditions:

   • operation_not_permitted — if the thread does not have the privilege to perform the operation.

   • resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.

   • device_or_resource_busy — if the mutex is already locked and blocking is not possible.

[ 2015-10 pre-Kona ]

SG1 hands this over to LWG for wording review

[ 2015-05 Lenexa, SG1 response ]

We believe we were already done with it. Should be in SG1-OK status.

[ 2015-02 Cologne ]

Handed over to SG1.

[ 2014-06-17 Rapperswil ]

Detlef provides wording

As discussed during the Chicago meeting in SG1 the only reasonable reasons for throwing device_or_resource_busy seem to be:

• The thread currently already holds the mutex, the mutex is not recursive, and the implementation detects this. In this case resource_deadlock_would_occur should be thrown.

• Priority reasons. At least std::mutex (and possibly all standard mutex types) should not be setup this way, otherwise we have real problems with condition_variable::wait().