This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

### 2309. `mutex::lock()` should not throw `device_or_resource_busy`

Section: 32.5.4.2 [thread.mutex.requirements.mutex] Status: C++17 Submitter: Detlef Vollmann Opened: 2013-09-27 Last modified: 2017-07-30

Priority: 0

View all other issues in [thread.mutex.requirements.mutex].

View all issues with C++17 status.

Discussion:

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()`.

[2014-06-17 Rapperswil]

Detlef provides wording

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

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

[2015-10 pre-Kona]

SG1 hands this over to LWG for wording review

[2015-10 Kona]

Geoffrey provides new wording.

Previous resolution [SUPERSEDED]:

> This wording is relative to N3936.

> 1. Change 32.5.4.2 [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.

Proposed resolution:

This wording is relative to N4527.

1. Change 32.5.4.2 [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 32.5.4.4 [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.

   > […]