Section: 32.6.4 [thread.mutex.requirements], 32.6.4.2.2 [thread.mutex.class], 32.6.4.2 [thread.mutex.requirements.mutex], 32.6.4.2.3 [thread.mutex.recursive], 32.6.4.3 [thread.timedmutex.requirements], 32.6.4.3.2 [thread.timedmutex.class], 32.6.4.3.3 [thread.timedmutex.recursive] Status: Pending NAD Editorial Submitter: Pete Becker Opened: 2012-01-16 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [thread.mutex.requirements].
View all other issues in [thread.mutex.requirements].
View all issues with Pending NAD Editorial status.
Discussion:
32.6.4.2.2 [thread.mutex.class]/3 says that the class mutex "shall satisfy all the Mutex
requirements (32.6.4 [thread.mutex.requirements])".
32.6.4.2.2 [thread.mutex.class] is part of 32.6.4 [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".
recursive_mutex
).
32.6.4.3 [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 32.6.4.3.2 [thread.timedmutex.class]/2
and 32.6.4.3.3 [thread.timedmutex.recursive]/2 should be turned into notes that refer to this new subclause and
to the new subclause in 32.6.4.2 [thread.mutex.requirements.mutex].
[See also issue 2125]
[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.
Proposed resolution: