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: 33.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:

[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 33.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 33.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 33.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.

    […]