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

   […]