[intro.races] How does a load operation of the mutex contribute to the modification order

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[intro.races.note] p3 says

a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex.

[intro.races.note] p6 says

All operations on a given mutex occur in a single total order. Each mutex acquisition “reads the value written” by the last mutex release.

This sounds like lock is an acquire load operation. Then [thread.mutex.requirements.mutex.general] p4 says

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.

Consider this example:

#include <mutex>

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

There is no wording that specifies that the total order of the object m is is #1 < #2 rather than #2 < #1. [intro.races] p11 says

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.

First, the mutex object is not an atomic object. Second, the atomic operations lock is not specified as modifications.

Suggested Resolution: