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.

### 893. `std::mutex` issue

Section: 33.6.4.2.2 [thread.mutex.class] Status: C++11 Submitter: Peter Dimov Opened: 2008-09-15 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.mutex.class].

View all issues with C++11 status.

Duplicate of: 905

Discussion:

33.6.4.2.2 [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.

[ Summit: ]

> Move to open. Proposed resolution:

> - In 33.6.4 [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 33.6.4.2.2 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object calls `lock()` or `try_lock()` on that object, or"

[ 2009-07 Frankfurt ]

> Move to Review. Alisdair to provide note.

[ 2009-07-31 Alisdair provided note. ]

[ 2009-10 Santa Cruz: ]

> Moved to Ready.

[ 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-11-18 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

Proposed resolution:

In 33.6.4 [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 33.6.4.2.2 [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 33.6.4.2.2 [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]