This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
resource_deadlock_would_occur
Section: 32.6.5.4.3 [thread.lock.unique.locking] Status: C++11 Submitter: LWG Opened: 2009-06-28 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [thread.lock.unique.locking].
View all issues with C++11 status.
Duplicate of: 1219
Discussion:
Addresses UK 327, UK 328
UK 327 Description
Not clear what
the specification for error condition
resource_deadlock_would_occur
means. It is perfectly
possible for this thread to own the mutex without setting
owns to true on this specific lock object. It is also
possible for lock operations to succeed even if the thread
does own the mutex, if the mutex is recursive. Likewise, if
the mutex is not recursive and the mutex has been locked
externally, it is not always possible to know that this
error condition should be raised, depending on the host
operating system facilities. It is possible that 'i.e.' was
supposed to be 'e.g.' and that suggests that recursive
locks are not allowed. That makes sense, as the
exposition-only member owns is boolean and not a integer to
count recursive locks.
UK 327 Suggestion
Add a precondition !owns
. Change the 'i.e.'
in the error condition to be 'e.g.' to allow for this
condition to propogate deadlock detection by the host OS.
UK 327 Notes
Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock means for recursive locks when you are the owner. POSIX has language on this, which should ideally be followed. Proposed fix is not quite right, for example, try_lock should have different wording from lock.
UK 328 Description
There is a missing precondition that owns
is true, or an if(owns)
test is missing from the effect
clause
UK 328 Suggestion
Add a
precondition that owns == true
. Add an error condition to
detect a violation, rather than yield undefined behaviour.
UK 328 Notes
Handle in same issue as UK 327. Also uncertain that the proposed resolution is the correct one.
[ 2009-11-11 Alisdair notes that this issue is very closely related to 1219(i), if not a dup. ]
[ 2010-02-12 Anthony provided wording. ]
[ 2010 Pittsburgh: ]
Wording updated and moved to Ready for Pittsburgh.
Proposed resolution:
Modify 32.6.5.4.3 [thread.lock.unique.locking] p3 to say:
void lock();...
3 Throws: Any exception thrown by
pm->lock()
.std::system_error
if an exception is required (32.2.2 [thread.req.exception]).std::system_error
with an error condition ofoperation_not_permitted
ifpm
is0
.std::system_error
with an error condition ofresource_deadlock_would_occur
if on entryowns
istrue
.std::system_error
when the postcondition cannot be achieved.
Remove 32.6.5.4.3 [thread.lock.unique.locking] p4 (Error condition clause).
Modify 32.6.5.4.3 [thread.lock.unique.locking] p8 to say:
bool try_lock();...
8 Throws: Any exception thrown by
pm->try_lock()
.std::system_error
if an exception is required (32.2.2 [thread.req.exception]).std::system_error
with an error condition ofoperation_not_permitted
ifpm
is0
.std::system_error
with an error condition ofresource_deadlock_would_occur
if on entryowns
istrue
.std::system_error
when the postcondition cannot be achieved.
Remove 32.6.5.4.3 [thread.lock.unique.locking] p9 (Error condition clause).
Modify 32.6.5.4.3 [thread.lock.unique.locking] p13 to say:
template <class Clock, class Duration> bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time);...
13 Throws: Any exception thrown by
pm->try_lock_until()
.std::system_error
if an exception is required (32.2.2 [thread.req.exception]).std::system_error
with an error condition ofoperation_not_permitted
ifpm
is0
.std::system_error
with an error condition ofresource_deadlock_would_occur
if on entryowns
istrue
.std::system_error
when the postcondition cannot be achieved.
Remove 32.6.5.4.3 [thread.lock.unique.locking] p14 (Error condition clause).
Modify 32.6.5.4.3 [thread.lock.unique.locking] p18 to say:
template <class Rep, class Period> bool try_lock_for(const chrono::duration<Rep, Period>& rel_time);...
18 Throws: Any exception thrown by
pm->try_lock_for()
.std::system_error
if an exception is required (32.2.2 [thread.req.exception]).std::system_error
with an error condition ofoperation_not_permitted
ifpm
is0
.std::system_error
with an error condition ofresource_deadlock_would_occur
if on entryowns
istrue
.std::system_error
when the postcondition cannot be achieved.
Remove 32.6.5.4.3 [thread.lock.unique.locking] p19 (Error condition clause).