Movatterモバイル変換

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

2023. Incorrect requirements forlock_guard andunique_lock

Section: 32.6.5.2[thread.lock.guard], 32.6.5.4[thread.lock.unique]Status:ResolvedSubmitter: Daniel KrüglerOpened: 2010-12-08Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [thread.lock.guard].

View all issues withResolved status.

Discussion:

There are two different*Lockable requirements imposed on template argumentsof the class templatelock_guard as of 32.6.5.2[thread.lock.guard] p. 1+2:

1 [..] The suppliedMutex type shall meet theBasicLockable requirements (30.2.5.2).

2 The suppliedMutex type shall meet theLockable requirements (30.2.5.3).

TheLockable requirements include the availability of a member functiontry_lock(),but there is no operational semantics in the specification oflock_guard that would relyon such a function. It seems to me that paragraph 2 should be removed.

Similarly, 32.6.5.4[thread.lock.unique] p. 1+2 refer to exactly the same two requirements.In this case it seems as if the intention was that the template arguementMutex shouldalways provide thetry_lock() member function, because several member functions ofunique_lock (unique_lock(mutex_type& m, try_to_lock_t) orbool try_lock()) take advantage of such a function without adding extra requirements for this.It seems that the requirement subsetBasicLockable should be removed.

I searched for further possible misusages of the*Lockable requirements, but could notfind any more.

[2011-02-23]

Howard suggests an alternative approach in regard tounique_lock: The currentminimum requirements on its template argument should better be reduced toBasicLockable instead of the currentLockable, including ammending member-wise constraints where required. This suggestions was supported by Anthony, Daniel, and Pablo.

Daniel drafts wording that follows this separation strategy.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

The suggested wording changes are against the working draft N3242.

1. Remove 32.6.5.2[thread.lock.guard] p. 2 completely:

   2 The suppliedMutex type shall meet theLockable requirements (30.2.5.3).

2. Change 32.6.5.4[thread.lock.unique] p. 1-3 as indicated. The intend is to makeBasicLockablethe fundamental requirement forunique_lock. We also update the note to reflect these changes andsynchronize one remaining reference of 'mutex' by the proper term 'lockable object' in syncto the wording changes oflock_guard:

   1 [..] The behavior of a program is undefined if the contained pointerpm is not nulland themutexlockable object pointed to bypm does not exist for the entire remaining lifetime (3.8) of theunique_lock object. The suppliedMutex type shall meet theBasicLockable requirements (30.2.5.2).[Editor's note:BasicLockable is redundant, since the following additional paragraph requires Lockable.]

   2 The suppliedMutex type shall meet theLockable requirements (30.2.5.3).

   3 [Note:unique_lock<Mutex> meets theBasicLockable requirements. IfMutex meets theLockable requirements ([thread.req.lockable.req]),unique_lock<Mutex> also meets theLockable requirements and ifMutex meets theTimedLockable requirements (30.2.5.4),unique_lock<Mutex> also meets theTimedLockable requirements. —end note ]

3. Modify 32.6.5.4.2[thread.lock.unique.cons] to add the now necessary member-wiseadditional constraints forLockable:

   unique_lock(mutex_type& m, try_to_lock_t) noexcept;

   8Requires:The suppliedMutex type shall meet theLockable requirements ([thread.req.lockable.req]). Ifmutex_type is not a recursive mutex the calling thread does not own the mutex.

   9Effects: Constructs an object of typeunique_lock and callsm.try_lock().

4. Modify 32.6.5.4.3[thread.lock.unique.locking] to add the now necessary member-wiseadditional constraints forLockable:

   bool try_lock();

   ?Requires: The suppliedMutex type shall meet theLockable requirements ([thread.req.lockable.req]).

   4Effects:pm->try_lock()

Proposed resolution:

Resolved 2011-03 Madrid meeting by paperN3278