Title
Unclear spec for resource_deadlock_would_occur
Status
c++11
Section
[thread.lock.unique.locking]
Submitter
LWG

Created on 2009-06-28.00:00:00 last changed 154 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

Modify [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 ([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 [thread.lock.unique.locking] p4 (Error condition clause).

Modify [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 ([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 [thread.lock.unique.locking] p9 (Error condition clause).

Modify [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 ([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 [thread.lock.unique.locking] p14 (Error condition clause).

Modify [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 ([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 [thread.lock.unique.locking] p19 (Error condition clause).

Date: 2010-10-21.18:28:33

[ 2010 Pittsburgh: ]

Wording updated and moved to Ready for Pittsburgh.

Date: 2010-02-12.00:00:00

[ 2010-02-12 Anthony provided wording. ]

Date: 2009-11-11.00:00:00

[ 2009-11-11 Alisdair notes that this issue is very closely related to 1219, if not a dup. ]

Date: 2009-06-28.00:00:00

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.

History
Date User Action Args
2011-08-23 20:07:26adminsetstatus: wp -> c++11
2010-10-21 18:28:33adminsetmessages: + msg959
2010-10-21 18:28:33adminsetmessages: + msg958
2010-10-21 18:28:33adminsetmessages: + msg957
2010-10-21 18:28:33adminsetmessages: + msg956
2009-06-28 00:00:00admincreate