LWG4519 No formal rule associates the total order of a mutex object with the rule for modification order

[jwakely]

https://cplusplus.github.io/LWG/issue4519

This needs SG1 to consider it.

[rarutyun]

SG1 looked at this in Croydon, March 2026

Poll: SG1 would like to see a paper that resolves LWG4519 by aligning the specification of mutex, condvar, semaphore, etc... instead of having 3+ ways of saying the same thing, in the following way:

1. Delete the comparison of mutex to atomic, in general, for example delete this text: from 32.6.4.2.1[thread.mutex.requirements.mutex.general] p4 For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]). [Note 2: This can be viewed as the modification order of the mutex. — end note]
2. Say instead that invocations of lock and unlock don't introduce data races (like semaphore): from 32.8.3[thread.sema.cnt]p3 Concurrent invocations of the member functions of counting_semaphore, other than its destructor, do not introduce data races.
3. Clarify the single total order is consistent with HB (like condition variable): from 32.7.1[thread.condition.general]p4 The implementation behaves as if all executions of notify_one, notify_all, and each part of the wait, wait_for, and wait_until executions are executed in a single unspecified total order consistent with the “happens before” order.

Outcome: No objection to unanimous consent

[xmh0511]

It would be worth noting that some operations behave like RMW operations; for example, the lock operation both needs to read and modify the state of the mutex. We do want coherence rules (i.e., [intro.races]), together with a total order, to apply to these facilities to rule out some impossible executions. For example, a lock() operation A obtains the ownership from an unlock operation B whose corresponding lock() obtains the ownership from A's unlock(), which will be rendered as an impossible execution due to an invalid total order.