Proposed resolution:

This wording is relative to N5032.

1. Modify [thread.mutex.requirements.mutex.general] as indicated:

   -4- The implementation provides lock and unlock operations, as described below. For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]) as if they were modifications to an atomic object. The lock and unlock operations on a single mutex appears to occur in a single total order, this can be viewed as the modification order of the atomic object.

[thread.mutex.requirements.mutex.general] p4 says (emphasis mine):

For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]). The lock and unlock operations on a single mutex appears to occur in a single total order.

The second note in [thread.mutex.requirements.mutex.general] p4

[Note 2: This can be viewed as the modification order of the mutex. — end note]

wants to inform the reader to interpret the single total order as a modification order. The review in LWG 4475 says:

For atomic objects, the modification order is already a single total order, `seq_cst` or not. This isn't a useful change.

This implies that we want the single total order of a mutex object to be considered as the modification order of an atomic object for defining the order of the single total order by existing rules (especially, [intro.races] p11-p14).

However, the wording in [thread.mutex.requirements.mutex.general] p1 (emphasis mine)

In this description, `m` denotes an object of a mutex type.

strongly implies that there is a difference between atomic objects and mutex objects. Except for the note, there is no formal wording to state that `lock()` and `unlock()` operations are modifications to the mutex object as if they were modifications to an atomic object for the purpose of determining the total order, that is, the rules defined in [intro.races] that applies to an atomic object can also apply to an mutex object.

For example:

#include <mutex>

std::mutex m;

int main(){
  m.lock(); // #1
  m.unlock(); // #2
}

The current formal wording only says `m` has a single total order. There is no formal wording that would associate the order of these operations in the total order of `m` with happens-before. We do want write-write coherence to apply to the total order of a mutex object. However, [intro.races] p11 (emphasis mine),

If an operation A that modifies an atomic object M happens before an operation B that modifies M, then A is earlier than B in the modification order of M.

only applies to an atomic object, as shown in the emphasized text. The definition of total order only says the order can be either #1 < #2 or #2 < #1, either one of which is valid. Presumably, the intended meaning should be that the total order of the mutex object `m` in this program is #1 < #2 according to happens-before and [intro.races] p11.