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

936. Mutex type overspecified

Section: 32.6.4 [thread.mutex.requirements] Status: LEWG Submitter: Pete Becker Opened: 2008-12-05 Last modified: 2017-03-01

Priority: Not Prioritized

View other active issues in [thread.mutex.requirements].

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

View all issues with LEWG status.

Duplicate of: 961

Discussion:

32.6.4 [thread.mutex.requirements] describes the requirements for a type to be a "Mutex type". A Mutex type can be used as the template argument for the Lock type that's passed to condition_variable_any::wait (although Lock seems like the wrong name here, since Lock is given a different formal meaning in 32.6.5 [thread.lock]) and, although the WD doesn't quite say so, as the template argument for lock_guard and unique_lock.

The requirements for a Mutex type include:

• m.lock() shall be well-formed and have [described] semantics, including a return type of void.
• m.try_lock() shall be well-formed and have [described] semantics, including a return type of bool.
• m.unlock() shall be well-formed and have [described] semantics, including a return type of void.

Also, a Mutex type "shall not be copyable nor movable".

The latter requirement seems completely irrelevant, and the three requirements on return types are tighter than they need to be. For example, there's no reason that lock_guard can't be instantiated with a type that's copyable. The rule is, in fact, that lock_guard, etc. won't try to copy objects of that type. That's a constraint on locks, not on mutexes. Similarly, the requirements for void return types are unnecessary; the rule is, in fact, that lock_guard, etc. won't use any returned value. And with the return type of bool, the requirement should be that the return type is convertible to bool.

[ Summit: ]

Move to open. Related to conceptualization and should probably be tackled as part of that.

• The intention is not only to place a constraint on what types such as lock_guard may do with mutex types, but on what any code, including user code, may do with mutex types. Thus the constraints as they are apply to the mutex types themselves, not the current users of mutex types in the standard.
• This is a low priority issue; the wording as it is may be overly restrictive but this may not be a real issue.

[ Post Summit Anthony adds: ]

Section 32.6.4 [thread.mutex.requirements] conflates the requirements on a generic Mutex type (including user-supplied mutexes) with the requirements placed on the standard-supplied mutex types in an attempt to group everything together and save space.

When applying concepts to chapter 30, I suggest that the concepts Lockable and TimedLockable embody the requirements for *use* of a mutex type as required by unique_lock/lock_guard/condition_variable_any. These should be relaxed as Pete describes in the issue. The existing words in 32.6.4 [thread.mutex.requirements] are requirements on all of std::mutex, std::timed_mutex, std::recursive_mutex and std::recursive_timed_mutex, and should be rephrased as such.

[2017-03-01, Kona]

SG1: Agreement that we need a paper.

Proposed resolution: