Proposed resolution:

In [thread.mutex.requirements] paragraph 12 change:

• ...
• resource_deadlock_would_occur -- if the current thread already owns the mutex and is able to detect it implementation detects that a deadlock would occur.
• ...

Strike [thread.mutex.class] paragraph 3 bullet 2:

-3- The behavior of a program is undefined if:

• ...
• a thread that owns a mutex object calls lock() or try_lock() on that object, or
• ...

Add the following note after p3 [thread.mutex.class]

[Note: a program may deadlock if the thread that owns a mutex object calls lock() on that object. If the implementation can detect the deadlock, a resource_deadlock_would_occur error condition may be observed. — end note]

[ 2009-11-18 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2009-11-18 Peter Opens: ]

I don't believe that the proposed note:

[Note: a program may deadlock if the thread that owns a mutex object calls lock() or try_lock() on that object. If the program can detect the deadlock, a resource_deadlock_would_occur error condition may be observed. — end note]

is entirely correct. "or try_lock()" should be removed, because try_lock is non-blocking and doesn't deadlock; it just returns false when it fails to lock the mutex.

Howard: I've set to Open and updated the wording per Peter's suggestion.

[ 2009-10 Santa Cruz: ]

Moved to Ready.

[ 2009-07-31 Alisdair provided note. ]

[ 2009-07 Frankfurt ]

Move to Review. Alisdair to provide note.

[ Summit: ]

Move to open. Proposed resolution:

• In [thread.mutex.requirements] paragraph 12, change the error condition for resource_deadlock_would_occur to: "if the implementation detects that a deadlock would occur"
• Strike [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object calls lock() or try_lock() on that object, or"

[thread.mutex.class]/27 (in N2723) says that the behavior is undefined if:

• a thread that owns a mutex object calls lock() or try_lock() on that object

I don't believe that this is right. Calling lock() or try_lock() on a locked mutex is well defined in the general case. try_lock() is required to fail and return false. lock() is required to either throw an exception (and is allowed to do so if it detects deadlock) or to block until the mutex is free. These general requirements apply regardless of the current owner of the mutex; they should apply even if it's owned by the current thread.

Making double lock() undefined behavior probably can be justified (even though I'd still disagree with the justification), but try_lock() on a locked mutex must fail.