Issue2309

Title 2309. mutex::lock() should not throw device_or_resource_busy
Status wp Section [thread.mutex.requirements.mutex]
Submitter Detlef Vollmann

Created on 2013-09-27.00:00:00 by admin, last changed by admin.

Messages
msg7575 (view) Date: 2015-10-22.17:39:12

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.

    […]

msg7563 (view) Date: 2015-10-22.17:39:12

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

msg7390 (view) Date: 2015-10-15.18:54:55

[ 2015-10 pre-Kona ]

SG1 hands this over to LWG for wording review

msg7322 (view) Date: 2015-05-08.04:23:26

[ 2015-05 Lenexa, SG1 response ]

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

msg7057 (view) Date: 2015-04-04.16:45:17

[ 2015-02 Cologne ]

Handed over to SG1.

msg7056 (view) Date: 2014-06-17.00:00:00

[ 2014-06-17 Rapperswil ]

Detlef provides wording

msg6681 (view) Date: 2013-09-27.00:00:00

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

History
Date User Action Args
2016-06-28 12:47:21adminsetstatus: ready -> wp
2016-03-07 04:46:57adminsetstatus: review -> ready
2015-10-22 17:39:12adminsetmessages: + msg7575
2015-10-15 18:54:55adminsetstatus: open -> review
2015-10-15 18:54:55adminsetmessages: + msg7563
2015-05-08 04:23:26adminsetmessages: + msg7390
2015-04-04 16:45:17adminsetstatus: new -> open
2015-04-04 16:45:17adminsetmessages: + msg7322
2014-06-17 11:57:48adminsetmessages: + msg7057
2014-06-17 11:57:48adminsetmessages: + msg7056
2013-09-27 00:00:00admincreate