Movatterモバイル変換

[0]ホーム

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

1268. The Mutex requirements in 30.4.1 and 30.4.2 are wrong

Section: 32.6[thread.mutex]Status:ResolvedSubmitter: Anthony WilliamsOpened: 2009-11-17Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [thread.mutex].

View all issues withResolved status.

Discussion:

TheMutex requirements in 32.6.4[thread.mutex.requirements] and32.6.4.3[thread.timedmutex.requirements] confuse the requirements on thebehaviour ofstd::mutex et al with the requirements onLockable types for use withstd::unique_lock,std::lock_guard andstd::condition_variable_any.

[2010 Pittsburgh:]

Concepts of threads chapter and issue presentation are: Lockable < Mutex <TimedMutex and Lockable < TimedLockable < TimedMutex.
Typo in failed deletion of Mutex in 30.4.4 p4 edits.
Lockable requirements are too weak for condition_variable_any, but the Mutexrequirements are too strong.
Need subset of Lockable requirements for condition_variable_any that does notinclude try_lock. E.g. CvLockable < Lockable.
Text needs updating to recent draft changes.
Needs to specify exception behavior in Lockable.
The current standard is fine for what it says, but it places requirements thatare too strong on authors of mutexes and locks.
Move to open status. Suggest Anthony look at condition_variable_anyrequirements. Suggest Anthony refine requirements/concepts categories.
Related to964⁽ⁱ⁾ and966⁽ⁱ⁾

[2010-03-28 Daniel synced with N3092.]

[2010-10-25 Daniel adds:]

Acceptingn3130 would solve this issue.

[2010-11 Batavia:]

Resolved by adoptingn3197.

Proposed resolution:

Add a new section to 32.2[thread.req] after 32.2.4[thread.req.timing] as follows:

30.2.5 Requirements for Lockable types
The standard library templatesunique_lock (32.6.5.4[thread.lock.unique]),lock_guard (32.6.5.2[thread.lock.guard]),lock,try_lock (32.6.6[thread.lock.algorithm]) andcondition_variable_any (32.7.5[thread.condition.condvarany]) all operate on user-suppliedLockable objects. Such an object must support the member functionsspecified for either theLockable Requirements or theTimedLockable requirements as appropriate to acquire or releaseownership of alock by a giventhread. [Note: thenature of any lock ownership and any synchronization it may entail are not partof these requirements. —end note]
30.2.5.1 Lockable Requirements
In order to qualify as aLockable type, the following expressions mustbe supported, with the specified semantics, wherem denotes a value oftypeL that supports theLockable:
The expressionm.lock() shall be well-formed and have the followingsemantics:
Effects:
Block until a lock can be acquired for the current thread.
Return type:
void
The expressionm.try_lock() shall be well-formed and have thefollowing semantics:
Effects:
Attempt to acquire a lock for the current thread without blocking.
Return type:
bool
Returns:
true if the lock was acquired,false otherwise.
The expressionm.unlock() shall be well-formed and have thefollowing semantics:
Effects:
Release a lock onm held by the current thread.
Return type:
void
Throws:
Nothing if the current thread holds a lock onm.
30.2.5.2TimedLockable Requirements
For a type to qualify asTimedLockable it must meet theLockable requirements, and additionally the followingexpressions must be well-formed, with the specified semantics,wherem is an instance of a typeTL that supportstheTimedLockable requirements,rel_time denotesinstantiation ofduration (30.5[time.duration]) andabs_timedenotes an instantiation oftime_point (30.6[time.point])
The expressionm.try_lock_for(rel_time) shall be well-formed and have thefollowing semantics:
Effects:
Attempt to acquire a lock for the current thread within the specified time period.
Return type:
bool
Returns:
true if the lock was acquired,false otherwise.
The expressionm.try_lock_until(abs_time) shall be well-formed and have thefollowing semantics:
Effects:
Attempt to acquire a lock for the current thread before the specified point in time.
Return type:
bool
Returns:
true if the lock was acquired,false otherwise.

Replace 32.6.4[thread.mutex.requirements] paragraph 2 with thefollowing:

2 This section describes requirements on~~template argument typesused to instantiate templates defined in~~the mutex typessupplied by the C++ standard library.~~The templatedefinitions in the C++ standard library refer~~ These types shallconform to the namedMutex requirements whose details are setout below. In this description,m is an objectof~~aMutex type~~one of the standard library mutex typesstd::mutex,std::recursive_mutex,std::timed_mutex orstd::recursive_timed_mutex..

Add the following paragraph after 32.6.4[thread.mutex.requirements]paragraph 2:

AMutex type shall conform to theLockablerequirements (30.2.5.1).

Replace 32.6.4.3[thread.timedmutex.requirements] paragraph 1 with thefollowing:

The C++ standard libraryTimedMutex typesstd::timed_mutex andstd::recursive_timed_mutex~~ATimedMutex type~~ shall meet the requirements foraMutex type. In addition,itthey shallmeet the requirements set out~~in this Clause 30.4.2~~below,whererel_time denotes an instantiation ofduration(30.5[time.duration]) andabs_time denotes an instantiationoftime_point (30.6[time.point]).

Add the following paragraph after 32.6.4.3[thread.timedmutex.requirements] paragraph 1:

ATimedMutex type shall conform to theTimedLockablerequirements (30.2.5.1).

Add the following paragraph following 32.6.5.2[thread.lock.guard]paragraph 1:

The suppliedMutex type shall meet theLockable requirements (30.2.5.1).

Add the following paragraph following 32.6.5.4[thread.lock.unique]paragraph 1:

The suppliedMutex type shall meet theLockable requirements(30.2.5.1).unique_lock<Mutex> meets theLockablerequirements. IfMutex meets theTimedLockable requirements(30.2.5.2) thenunique_lock<Mutex> also meets theTimedLockable requirements.

Replace the use of "mutex" or "mutex object" with "lockable object"throughout clause 32.6.5[thread.lock] paragraph 1:

1 A lock is an object that holds a reference toa~~mutex~~lockable object and may unlockthe~~mutex~~lockable object during the lock'sdestruction (such as when leaving block scope). A thread of executionmay use a lock to aid in managing~~mutex~~ ownershipof alockable object in an exception safe manner. A lock is said toown a~~mutex~~lockable object if it is currentlymanaging the ownership of that~~mutex~~lockableobject for a thread of execution. A lock does not manage thelifetime of the~~mutex~~lockable object itreferences. [ Note: Locks are intended to ease the burden ofunlocking the~~mutex~~lockable object under bothnormal and exceptional circumstances. — end note ]

32.6.5[thread.lock] paragaph 2:

2 Some lock constructors take tag types which describe what should bedone with the~~mutex~~lockable object during thelock's constuction.

32.6.5.2[thread.lock.guard] paragaph 1:

1 An object of typelock_guard controls the ownership of a~~mutex~~lockable object within a scope. Alock_guard object maintains ownership ofa~~mutex~~lockable object throughoutthelock_guard object's lifetime. The behavior of a programis undefined if the~~mutex~~lockable objectreferenced bypm does not exist for the entire lifetime (3.8)of thelock_guard object.Mutex shall meet theLockable requirements (30.2.5.1).

32.6.5.4[thread.lock.unique] paragaph 1:

1 An object of typeunique_lock controls the ownership ofa~~mutex~~lockable object within ascope.~~Mutex~~oOwnershipof thelockable object may be acquired at construction or afterconstruction, and may be transferred, after acquisition, toanotherunique_lock object. Objects oftypeunique_lock are not copyable but are movable. Thebehavior of a program is undefined if the containedpointerpm is not null and the mutex pointed tobypm does not exist for the entire remaining lifetime (3.8)of theunique_lock object.Mutex shall meettheLockable requirements (30.2.5.1).

Add the following to the precondition ofunique_lock(mutex_type&m, const chrono::time_point<Clock, Duration>& abs_time) in 32.6.5.4.2[thread.lock.unique.cons] paragraph 18:

template <class Clock, class Duration>  unique_lock(mutex_type& m, const chrono::time_point<Clock, Duration>& abs_time);
18Requires: Ifmutex_type is not a recursive mutex the calling thread does not own the mutex.The suppliedmutex_typetype shall meet theTimedLockable requirements (30.2.5.2).

Add the following to the precondition ofunique_lock(mutex_type& m,const chrono::duration<Rep, Period>& rel_time) in 32.6.5.4.2[thread.lock.unique.cons]paragraph 22

22Requires: Ifmutex_type is not a recursive mutex thecalling thread does not own the mutex.The suppliedmutex_typetype shall meet theTimedLockable requirements (30.2.5.2).

Add the following as a precondition ofbool try_lock_until(constchrono::time_point<Clock, Duration>& abs_time) before32.6.5.4.3[thread.lock.unique.locking] paragraph 8

template <class Clock, class Duration>  bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time);
Requires: The suppliedmutex_type type shall meet theTimedLockable requirements (30.2.5.2).

Add the following as a precondition ofbool try_lock_for(constchrono::duration<Rep, Period>& rel_time) before 32.6.5.4.3[thread.lock.unique.locking] paragraph 12

template <class Rep, class Period>  bool try_lock_for(const chrono::duration<Rep, Period>& rel_time);
Requires: The suppliedmutex_type type shall meet theTimedLockable requirements (30.2.5.2).

Replace 32.6.6[thread.lock.algorithm] p1 with the following:

template <class L1, class L2, class... L3> int try_lock(L1&, L2&, L3&...);
1Requires: Each template parameter type shall meet theMutexLockable requirements(30.2.5.1).~~, except that a call totry_lock() may throw an exception.~~ [Note: Theunique_lock class template meets these requirements when suitably instantiated. —end note]

Replace 32.6.6[thread.lock.algorithm] p4 with the following:

template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...);
4Requires: Each template parameter type shall meet theMutexMutexLockablerequirements(30.2.5.1).~~, except that a call totry_lock() may throw an exception.~~ [Note: Theunique_lock class template meets these requirements when suitably instantiated. —end note]

Replace 32.7.5[thread.condition.condvarany] paragraph 1 with:

1 ALock type shall meet the~~requirements for aMutextype~~Lockable requirements (30.2.5.1), except thattry_lock is not required. [Note: All of the standard mutex types meet this requirement. —end note]

[8]ページ先頭