Unexpected productivity boost of Rust

I always thought that the POSIX threads semantics that forces the thread acquiring the lock to be the same thread that releases it, is too strict and not needed. In certain use cases it forces you to redesign the code in more complicated ways.

It isn't too strict. Releasing a pthread_mutex has the semantics of being a release memory barrier, which means that any writes on that thread will be visible by other threads that issue a subsequent acquire memory barrier (e.g. by acquiring the mutex).

If you want this behavior, it's relatively simple to implement your own mutex on top of futex, but no one is going to expect the behavior it provides.

I used to think that way, but I've learned that there's one good reason for why the API is designed that way: priority inheritance. Priorities are bound to threads, and, when a high priority threads wants to lock a currently occupied mutex, we want to bump the priority of the current holder. And POSIX requirement makes that easy --- the thread who locked the mutex must be the one holding it.

Related: https://man7.org/linux/man-pages/man2/futex.2.html#:~:text=%...