krisvale wrote
----
There is no barrier in use on the read part.  I realize that this is a subtle point, but in fact, the atomic functions make no memory barrier guarantees either (I think).  And even if they did, you are not using a memory barrier when you read the 'timeouts' to perform the subtraction.  On a multiprocessor machine the two values can easily fall on two cache lines and become visible to the other cpu in a random fashion.  In other words:  One cpu decreases the "owner" and "timeouts" at about the same time.  A different thread, on a different cpu may see the decrease in "owner" but not the decrease in "timeouts" until at some random later point.
----

From the webpage you linked to:
----
Sometimes the read or write that acquires or releases a resource is done using one of the InterlockedXxx functions. On Windows this simplifies things, because on Windows, the InterlockedXxx functions are all full-memory barriers—they effectively have a CPU memory barrier both before and after them, which means that they are a full read-acquire or write-release barrier all by themselves.
----

Interlocked functions would be pretty useless for implementing mutexes if they did not also act as some kind of barrier: preventing two threads from manipulating an object at the same time is not much use if they don't also get up-to-date views of that object while they own the lock.

Given that mutex->timeout is only modified by interlocked functions, an unprotected read of mutex->timeout will get a value which is at least as fresh as the one available the last time we crossed a barrier by calling InterlockedXXX() or WaitForSingleObject().

Note that if the read of mutex->timeouts in this line

    if ((timeouts = mutex->timeouts) != 0)

gives the "wrong" answer it will be an underestimate because we own the lock and the only other threads which might interfere will be incrementing the counter.  The worst that can happen is that the fast path remains blocked: consistency is not affected.