Section: 220.127.116.11.1 [thread.mutex.class] Status: Dup Submitter: Herb Sutter Opened: 2008-09-18 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [thread.mutex.class].
View all issues with Dup status.
Duplicate of: 893
A few questions on the current WP, N2723:
33.4.3 [thread.mutex.requirements]/24 says an expression mut.unlock() "Throws: Nothing." I'm assuming that, per 18.104.22.168 [res.on.required], errors that violate the precondition "The calling thread shall own the mutex" opens the door for throwing an exception anyway, such as to report unbalanced unlock operations and unlocking from a thread that does not have ownership. Right?
22.214.171.124.1 [thread.mutex.class]/3 (actually numbered paragraph "27" in the WP; this is just a typo I think) says
The behavior of a program is undefined if:
- it destroys a mutex object owned by any thread,
- a thread that owns a mutex object calls lock() or try_lock() on that object, or
- a thread terminates while owning a mutex object.
As already discussed, I think the second bullet should be removed, and such a lock() or try_lock() should fail with an exception or returning false, respectively.
A potential addition to the list would be
but without that the status quo text endorses the technique of the program logically transferring ownership of a mutex to another thread with correctness enforced by programming discipline. Was that intended?
[ Summit: ]
Two resolutions: "not a defect" and "duplicate", as follows:
- 33.4.3 [thread.mutex.requirements]/24: NAD. If the precondition fails the program has undefined behaviour and therefore an implementation may throw an exception already.
- 126.96.36.199.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue 893.
- 188.8.131.52.1 [thread.mutex.class]/3 proposed addition: NAD. This is already covered by the mutex requirements, which have ownership as a Precondition.