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.5.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.5.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.5.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.5.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.5.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: