Proposed resolution:

This wording is relative to N4527.

1. Change [thread.mutex.requirements.mutex] as indicated:

   -1- The mutex types are the standard library types std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex, std::shared_mutex, and std::shared_timed_mutex. They shall meet the MutexType requirements set out in this section. In this description, m denotes an object of a mutex type.

   -2- The mutex types shall meet the Lockable requirements ([thread.req.lockable.req]).

2. Change [thread.mutex.class] as indicated:

   -3- The class mutex shall satisfy all the MutexType requirements ([thread.mutex.requirements.mutex][thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

3. Change [thread.mutex.recursive] as indicated:

   -2- The class recursive_mutex shall satisfy all the MutexMutexType requirements ([thread.mutex.requirements.mutex][thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

4. Change [thread.timedmutex.requirements] as indicated:

   -1- The timed mutex types are the standard library types std::timed_mutex, std::recursive_timed_mutex, and std::shared_timed_mutex. They shall meet the TimedMutexType requirements set out below. In this description, m denotes an object of a mutex type, rel_time denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

   -2- The timed mutex types shall meet the TimedLockable requirements ([thread.req.lockable.timed]).

5. Change [thread.timedmutex.class] as indicated:

   -2- The class timed_mutex shall satisfy all of the TimedMutexType requirements ([thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

6. Change [thread.timedmutex.recursive] as indicated:

   -2- The class recursive_timed_mutex shall satisfy all of the TimedMutexType requirements ([thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

7. Change [thread.sharedmutex.requirements] as indicated: [Drafting note: The reference to the mutex types requirements has been moved after introducing the new requirement set to ensure that SharedMutexType refines MutexType.]

   -1- The standard library types std::shared_mutex and std::shared_timed_mutex are shared mutex types. Shared mutex types shall meet the SharedMutexType requirements of mutex types ([thread.mutex.requirements.mutex]), and additionally shall meet the requirements set out below. In this description, m denotes an object of a shared mutex type.

   -?- The shared mutex types shall meet the MutexType requirements ([thread.mutex.requirements.mutex]).

8. Change [thread.sharedmutex.class] as indicated:

   -2- The class shared_mutex shall satisfy all of the SharedMutexType requirements for shared mutexes ([thread.sharedmutex.requirements]). It shall be a standard-layout class (Clause 9).

9. Change [thread.sharedtimedmutex.requirements] as indicated: [Drafting note: The reference to the timed mutex types requirements has been moved after introducing the new requirement set to ensure that SharedTimedMutexType refines TimedMutexType and SharedMutexType.]

   -1- The standard library type std::shared_timed_mutex is a shared timed mutex type. Shared timed mutex types shall meet the SharedTimedMutexType requirements of timed mutex types ([thread.timedmutex.requirements]), shared mutex types ([thread.sharedmutex.requirements]), and additionally shall meet the requirements set out below. In this description, m denotes an object of a shared timed mutex type, rel_type denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

   -?- The shared timed mutex types shall meet the TimedMutexType requirements ([thread.timedmutex.requirements]) and the SharedMutexType requirements ([thread.sharedmutex.requirements]).

10. Change [thread.sharedtimedmutex.class] as indicated:

    -2- The class shared_timed_mutex shall satisfy all of the SharedTimedMutexType requirements for shared timed mutexes ([thread.sharedtimedmutex.requirements]). It shall be a standard-layout class (Clause 9).

11. Change [thread.lock.shared] as indicated:

    -1- […] The supplied Mutex type shall meet the shared mutexSharedMutexType requirements ([thread.sharedtimedmutex.requirements][thread.sharedmutex.requirements]).

    -2- [Note: shared_lock<Mutex> meets the TimedLockable requirements (30.2.5.4). — end note]

12. Change [thread.lock.shared.cons] as indicated:

    template <class Clock, class Duration>
      shared_lock(mutex_type& m,
                  const chrono::time_point<Clock, Duration>& abs_time);
    

    -14- Requires: The supplied Mutex type shall meet the SharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]). The calling thread does not own the mutex for any ownership mode.

    -15- Effects: Constructs an object of type shared_lock and calls m.try_lock_shared_until(abs_time).

    […]

    template <class Rep, class Period>
      shared_lock(mutex_type& m,
                  const chrono::duration<Rep, Period>& rel_time);
    

    -17- Requires: The supplied Mutex type shall meet the SharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]). The calling thread does not own the mutex for any ownership mode.

    -18- Effects: Constructs an object of type shared_lock and calls m.try_lock_shared_for(rel_time).

    […]

13. Change [thread.lock.shared.locking] as indicated:

    template <class Clock, class Duration>
      bool
      try_lock_until(const chrono::time_point<Clock, Duration>& abs_time);
    

    -?- Requires: The supplied Mutex type shall meet the SharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]).

    -8- Effects: pm->try_lock_shared_until(abs_time).

    […]

    template <class Rep, class Period>
      bool try_lock_for(const chrono::duration<Rep, Period>& rel_time);
    

    -?- Requires: The supplied Mutex type shall meet the SharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]).

    -12- Effects: pm->try_lock_shared_for(rel_time).

    […]

[ 2021-05-18 Resolved by the adoption of P2160R1 at the February 2021 plenary. Status changed: Open → Resolved. ]

[ 2018-08-23 Batavia Issues processing ]

Tim to redraft.

[ 2016-02 Jacksonville ]

Marshall to review wording.

[ 2015-10-21 Kona, Daniel comments and adjusts wording to to untimed shared mutex types ]

The new wording reflects the addition of the new shared mutex types. The approach used for shared_lock is similar to the one used for unique_lock: The template argument Mutex has a reduced requirement set that is not sufficient for all operations. Only those members that require stronger requirements of SharedTimedMutexType specify that additionally in the Requires element of the corresponding prototype specifications.

The proposed wording could be more general if we would introduce more fundamental requirements set for SharedLockable and SharedTimedLockable types which could be satisfied by user-provided types as well, because the SharedMutexType and SharedTimedMutexType requirements are essentially restricted to an enumerated set of types provided by the Standard Library. But this extension seemed too large for this issue and can be easily fixed later without any harm.

Previous resolution [SUPERSEDED]:

This wording is relative to N3936.

1. Change [thread.mutex.requirements.mutex] as indicated:

   -1- The mutex types are the standard library types std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex, and std::shared_timed_mutex. They shall meet the MutexType requirements set out in this section. In this description, m denotes an object of a mutex type.

2. Change [thread.mutex.class] as indicated:

   -3- The class mutex shall satisfy all the MutexType requirements ([thread.mutex.requirements.mutex][thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

3. Change [thread.mutex.recursive] as indicated:

   -2- The class recursive_mutex shall satisfy all the MutexMutexType requirements ([thread.mutex.requirements.mutex][thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

4. Change [thread.timedmutex.requirements] as indicated:

   -1- The timed mutex types are the standard library types std::timed_mutex, std::recursive_timed_mutex, and std::shared_timed_mutex. They shall meet the TimedMutexType requirements set out below. In this description, m denotes an object of a mutex type, rel_time denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

5. Change [thread.timedmutex.class] as indicated:

   -2- The class timed_mutex shall satisfy all of the TimedMutexType requirements ([thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

6. Change [thread.timedmutex.recursive] as indicated:

   -2- The class recursive_timed_mutex shall satisfy all of the TimedMutexType requirements ([thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

7. Change [thread.sharedtimedmutex.requirements] as indicated: [Drafting note: The reference to the timed mutex types requirements has been moved after introducing the new requirement set to ensure that SharedTimedMutexType refine TimedMutexType.]

   -1- The standard library type std::shared_timed_mutex is a shared timed mutex type. Shared timed mutex types shall meet the SharedTimedMutexType requirements of timed mutex types ([thread.timedmutex.requirements]), and additionally shall meet the requirements set out below. In this description, m denotes an object of a mutex type, rel_type denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

   -?- The shared timed mutex types shall meet the TimedMutexType requirements ([thread.timedmutex.requirements]).

8. Change [thread.sharedtimedmutex.class] as indicated:

   -2- The class shared_timed_mutex shall satisfy all of the SharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]). It shall be a standard-layout class (Clause 9).

9. Change [thread.lock.shared] as indicated: [Drafting note: Once N3995 has been applied, the following reference should be changed to the new SharedMutexType requirements ([thread.sharedmutex.requirements]) or even better to some new SharedLockable requirements (to be defined) — end drafting note]

   -1- […] The supplied Mutex type shall meet the shared mutexSharedTimedMutexType requirements ([thread.sharedtimedmutex.requirements]).

   -2- [Note: shared_lock<Mutex> meets the TimedLockable requirements (30.2.5.4). — end note]

[ 2015-10 pre-Kona ]

SG1 hands this over to LWG for wording review

[ 2015-05 Lenexa, SG1 response ]

Thanks to Daniel, and please put it in SG1-OK status. Perhaps open another issue for the remaining problem Daniel points out?

[ 2015-02 Cologne ]

Handed over to SG1.

[ 2014-06-08, Daniel comments and provides wording ]

The presented wording adds to the existing mutex types, timed mutex types, and shared timed mutex types terms a new set of corresponding MutexType, TimedMutexType, and SharedTimedMutexType requirements.

The reason for the change of requirement names is two-fold: First, the new name better matches the intention to have a concrete name for the requirements imposed on the corresponding mutex types (This kind of requirement deviate from the more general Lockable requirements, which are not restricted to a explicitly enumerated set of library types). Second, using **MutexType over **Mutex provides the additional advantage that it reduces the chances of confusing named requirements from template parameters named Mutex (such as for unique_lock or shared_lock).

Nonetheless the here presented wording has one unfortunate side-effect: Once applied it would have the effect that types used to instantiate std::shared_lock cannot be user-defined shared mutex types due to [thread.lock.shared]. The reason is based on the currently lack of an existing SharedLockable requirement set, which would complete the existing BasicLockable and Lockable requirements (which are "real" requirements). This restriction is not actually a problem introduced by the provided resolution but instead one that existed before but becomes more obvious now.

[ 2014-05-22, Daniel comments ]

As for SharedTimedMutex, there exists a similar problem in regard to TimedMutex referred to in [thread.timedmutex.class] p2 and in [thread.timedmutex.recursive] p2, but nowhere defined.

Another problem is, that according to [thread.mutex.class] p3, "The class mutex shall satisfy all the Mutex requirements ([thread.mutex.requirements]).", but there are no concrete Mutex requirements, [thread.mutex.requirements] — titled as "Mutex requirements" — describes mutex types, timed mutex types, and shared timed mutex types.

[thread.sharedtimedmutex.class] paragraph 2:

The class shared_timed_mutex shall satisfy all of the SharedTimedMutex requirements (30.4.1.4). It shall be a standard layout class (Clause 9).

There's no SharedTimedMutex requirements; this name doesn't appear anywhere else in the standard. (Prior to N3891, this was SharedMutex, which was equally undefined.)

I assume this concept should be defined somewhere?

Also, n3891 changes [thread.sharedtimedmutex.requirements] from defining "shared mutex type" to defining "shared timed mutex type", but its paragraph 2 still talks about "shared mutex type". Is that OK? I think you could argue that it's clear enough what it means, but presumably it should use the term that paragraph 1 defined.

[thread.lock.shared] paragraph 1 talks about the "shared mutex requirements", which again is a term that isn't defined, and presumably means "the requirements on a shared timed mutex type" or similar (maybe if SharedMutex or SharedTimedMutex were defined it could be reused here).