r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

cc @alexcrichton

Can you add a comment in the code as well explaining why one might expect us to use a CRITICAL_SECTION but we're instead using a SRWLOCK?

Other than that though r=me, nice find!

Comment added and rebased.
r?

We already use the unfair SRWLock for RWLock and the documentation makes no claims about fairness.
I can't find any solid information on the fairness of pthread_mutex and pthread_rwlock.

I'd be fine with holding off on this PR until a design consensus is made regarding the fairness of the locks that Rust provides. In the meantime someone can add a simple flag/semaphore/whatever to Mutex to fix the recursive locking issue.

When stabilizing the std::sync::Mutex interfaces, the fairness of the primitive came up, but it was decided that for now we're not going to provide any guarantee of fairness either fair or unfair (largely pending investigation like this on various systems). For now the purpose of this type is just to serve as a mutual exclusion primitive.

The current plan is to definitely allow for these primitives to grow in the future with perhaps a new FairMutex type or a Mutex::new_fair constructor or something like that. We also have room before the final release to refine the fairness semantics of a mutex and explicitly define it as "fast and unfair" or fair, but fixing a soundness hole on Windows is likely most important for now.

Needs a rebase

Rebased

@retep998 needs a rebase

Rebased.

Rebased again...