Locking

Note: all my experience is in user space, using Rust with access to the std library.

> How would the compiler verify that a call you've added in the area under mutex will not lead to the same mutex being grabbed?

In some cases, tools can find this. For example in this Playground link I lock a mutex twice. The compiler will build and run the executable but deadlocks. If we use Tools->Miri, the issue is found. But I think this is found by running the program in an interpreter rather than detecting it at compile time.

https://play.rust-lang.org/?version=stable&mode=debug...

For more elaborate issues, the language will make the types messier and messier to work with as you venture further out of bounds.

For example if you have a `my_lock = std::sync::Mutex<MyData>` then getting access to `MyData` involves calling `my_lock.lock()` which gives a `MutexGuard<MyData>`. You can't pass a `MutexGuard<MyData>` to a function expecting `&MyData` so you need to try to get the reference to `&*MyData` - a reference to a dereference. Already, this is looking a bit weird and hopefully helps a reviewer. But you also have the MyData reference and pass that around.

While I C you might think 'how can I get access to the pointer and make sure it's locked', in the Rust case if you can find access to the reference then you know it's locked - otherwise it would have still been behind the Mutex wrapper.