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.

### 1159. Unclear spec for `resource_deadlock_would_occur`

Section: 33.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, if not a dup. ]

[ 2010-02-12 Anthony provided wording. ]

[ 2010 Pittsburgh: ]

> Wording updated and moved to Ready for Pittsburgh.

Proposed resolution:

Modify 33.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 (33.2.2 [thread.req.exception]). `std::system_error` with an error condition of `operation_not_permitted` if `pm` is `0`. `std::system_error` with an error condition of `resource_deadlock_would_occur` if on entry `owns` is `true`. `std::system_error` when the postcondition cannot be achieved.

Remove 33.6.5.4.3 [thread.lock.unique.locking] p4 (Error condition clause).

Modify 33.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 (33.2.2 [thread.req.exception]). `std::system_error` with an error condition of `operation_not_permitted` if `pm` is `0`. `std::system_error` with an error condition of `resource_deadlock_would_occur` if on entry `owns` is `true`. `std::system_error` when the postcondition cannot be achieved.

Remove 33.6.5.4.3 [thread.lock.unique.locking] p9 (Error condition clause).

Modify 33.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 (33.2.2 [thread.req.exception]). `std::system_error` with an error condition of `operation_not_permitted` if `pm` is `0`. `std::system_error` with an error condition of `resource_deadlock_would_occur` if on entry `owns` is `true`. `std::system_error` when the postcondition cannot be achieved.

Remove 33.6.5.4.3 [thread.lock.unique.locking] p14 (Error condition clause).

Modify 33.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 (33.2.2 [thread.req.exception]). `std::system_error` with an error condition of `operation_not_permitted` if `pm` is `0`. `std::system_error` with an error condition of `resource_deadlock_would_occur` if on entry `owns` is `true`. `std::system_error` when the postcondition cannot be achieved.

Remove 33.6.5.4.3 [thread.lock.unique.locking] p19 (Error condition clause).