Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.

893.std::mutex issue

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

Priority:Not Prioritized

View all otherissues in [thread.mutex.class].

View all issues withC++11 status.

Duplicate of:905

Discussion:

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

• a thread that owns amutex object callslock() ortry_lock() on that object

I don't believe that this is right. Callinglock() ortry_lock() on alockedmutex is well defined in the general case.try_lock() is requiredto fail and returnfalse.lock() is required to either throw anexception (and is allowed to do so if it detects deadlock) or to blockuntil themutex is free. These general requirements apply regardless ofthe current owner of themutex; they should apply even if it's owned bythe current thread.

Making doublelock() undefined behavior probably can be justified (eventhough I'd still disagree with the justification), buttry_lock() on alockedmutex must fail.

[Summit:]

Move to open. Proposed resolution:

• In 32.6.4[thread.mutex.requirements] paragraph 12, change the errorcondition forresource_deadlock_would_occur to: "if the implementationdetects that a deadlock would occur"
• Strike 32.6.4.2.2[thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex objectcallslock() ortry_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 amutexobject callslock() ortry_lock() on that object. If the program candetect the deadlock, aresource_deadlock_would_occur error condition maybe observed. —end note]

is entirely correct. "ortry_lock()" should be removed, becausetry_lock is non-blocking and doesn't deadlock; it just returnsfalse 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 thecurrent thread already owns the mutex and is able to detect itimplementation 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 amutex object callslock() ortry_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 amutexobject callslock() on that object. If the implementation can detect thedeadlock, aresource_deadlock_would_occur error condition may beobserved. —end note]