Mutexes are recursive on windows, but not on unix

[alexcrichton]

This behavioral difference should factor into the stabilization of the methods on sync::Mutex and how we'd like to word the documentation.

For now though, this is a tracking issue as this difference in behavior was not originally intended.

cc @aturon

[pythonesque]

How can this make the semantics of the Mutex API differ substantially? You have a &mut borrow of the value protected by the Mutex, so even if the Mutex is reentrant I don't see how you could expose that through the API. Or I guess the issue is that you could get aliased &muts by clone()ing a Arc<Mutex<T>> on Windows and unlocking both in the same thread?

[alexcrichton]

Unfortunately the &mut borrow is earned from the MutexGuard structure, not the Mutex, which allows you lock it twice. For example, if this code completed, it could exhibit memory unsafety (two &mutreferences):

use std::sync::Mutex;
use std::mem;

fn main() {
    let m = Mutex::new(4u);
    let mut g1 = m.lock();
    let mut g2 = m.lock();

    let p1 = &mut *g1;
    let p2 = &mut *g2;
    mem::swap(p1, p2);
}

On unix that code deadlocks, but on windows it executes just fine.

[pythonesque]

Wait, lock() doesn't take a mutable reference to the Mutex? Weird, isn't that guaranteed to deadlock on Unix?

Anyway, since you could have aliased Mutexs in the same thread even if that were changed, I think Windows mutexes need an additional check for safety (Windows fast mutexes look like they have too many limitations to be a drop in replacement).

[sfackler]

lock can't take &mut self. That'd be a guarantee that the caller has exclusive access to the mutex, which defeats the entire point.

[pythonesque]

Oh right, it has to be shared in the first place. Heh.

[retep998]

What are the limitations of fast mutexes that prevent us from using them?

[pythonesque]

@sivadeilra and I discussed this and he recommends just adding a flag and checking it manually on Windows.

[alexcrichton]

@retep998 I don't think there are any limitations (we're currently using them), this is just a surprising consequence of using them.

@pythonesque yeah I suspect that sys::mutex::Mutex will have specific code on windows for a separate UnsafeCell<uint> which is inspected once the lock is acquired (using GetCurrentThreadId) and if the same thread acquires the mutex twice it just panics.

[retep998]

According to the current code we use Critical Sections for Mutexes on Windows.
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/mutex.rs
Fast/Guarded mutexes are a separate thing entirely and will deadlock if you attempt to lock them twice on the same thread.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545716%28v=vs.85%29.aspx
The MSVC C++ implementation for std::mutex checks if the locked thread is the current thread before even trying to lock it and throws an exception if it is.

[alexcrichton]

Whoa! I had no idea that "fast mutexes" was a thing. I thought there were only inter-process mutexes and critical sections.

It looks like the "fast mutexes" or "guarded mutexes" are only for drivers, and maybe not for userland code? Or at least I couldn't figure out how to use them. Do you have pointers to the source for MSVC's implementation, or how to use them?

[pythonesque]

Yeah, the bits that made it seem like they were only for drivers was why I said we probably couldn't use them. Apparently critical sections are the fastest userland ones you should use. On a related note, it might be worth clarifying in the Mutex documentation that they aren't intended to be used between processes (maybe it's already there, but I don't recall seeing it).

[retep998]

According to some debugging, on Windows 8.1 x64, MSVC uses SRWLock for std::mutex instead of CriticalSection. I'm going to do some benchmarking to determine their performance difference. As an added bonus, you can sleep a ConditionVariable on an SRWLock in Windows which Rust could provide as a platform specific extension trait.

[retep998]

And this is pretty conclusive. I did a test with two threads constantly locking and unlocking the same mutex. When I used CriticalSection it took about 260ns per lock+unlock. When I used SRWLock it took about 60ns per lock+unlock.
http://puu.sh/dSHEP/c304111d25.txt