[ 2012, Portland: move to Tentatively NAD Editorial ]

Seems no real ambiguity. May need some reorg of text rather then changing the wording.

Is there much that needs to be changed? But Pete's suggestion of putting requirement in separate sub section is good. Should be the direction to editor.

Suggest this is an editorial change. Happy with Pete's comments.

[ See also issue 2125 ]

[thread.mutex.class]/3 says that the class mutex "shall satisfy all the Mutex requirements ([thread.mutex.requirements])". [thread.mutex.class] is part of [thread.mutex.requirements], so at the very least, this requirement is recursive. But worse, there is nothing that says what "the Mutex requirements" refers to. For example, the "Lockable requirements" section starts with "A type L meets the Lockable requirements if …". There is no such statement for "the Mutex requirements".

Organizationally, paragraphs 1-26 in [thread.mutex.requirements.mutex] should probably be in a subclause with a name. (This is actually an ISO requirement, to avoid exactly this kind of ambiguous referencing) Then the first sentence of [thread.mutex.class]/3 can become a note: "The class mutex meets the requirements of (whatever)", since that subclause already says that the mutex types "shall meet the requirements set out in this section."

And similarly for [thread.mutex.recursive]/2 (recursive_mutex).

[thread.timedmutex.requirements], Timed mutex types, also needs the same rearrangement: its introductory requirements should be moved into a subclause, and the first sentences of [thread.timedmutex.class]/2 and [thread.timedmutex.recursive]/2 should be turned into notes that refer to this new subclause and to the new subclause in [thread.mutex.requirements.mutex].