Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue893 below:

Issue 893: std::mutex issue

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.

Section: 32.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:

32.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 32.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 32.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 32.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 32.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 32.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]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4