Question: A coworker had an issue recently that boiled down to what we believe was the following sequence of events in a C++ application with two threads:

* Thread A holds a mutex.
* While thread A is holding the mutex, thread B attempts to lock it. Since it is held, thread B is suspended.
* Thread A finishes the work that it was holding the mutex for, thus releasing the mutex.
* Very shortly thereafter, thread A needs to touch a resource that is protected by the mutex, so it locks it again.
* It appears that thread A is given the mutex again; thread B is still waiting, even though it "asked" for the lock first.

Does this sequence of events fit with the semantics of, say, C++11's `std::mutex` and/or pthreads? I can honestly say I've never thought about this aspect of mutexes before.

Are there any fairness guarantees to prevent starvation of other threads for too long, or any way to get such guarantees?

Answer: 
Known problem. C++ mutexes are thin layer on top of OS-provided mutexes, and OS-provided mutexes are often not fair. They do not care for FIFO.

The other side of the same coin is that threads are usually not pre-empted until they run out of their time slice. As a result, thread A in this scenario was likely to continue to be executed, and got the mutex right away because of that.
The logic here is very simple - the thread is not preempted based on mutexes, because that would require a cost incurred for each mutex operation, which is definitely not what you want. The cost of grabbing a mutex is high enough without forcing the scheduler to look for other threads to run.

If you want to fix this you can always yield the current thread. You can use std::this\_thread::yield() - <http://en.cppreference.com/w/cpp/thread/yield> - and that *might* offer the chance to thread B to take over the mutex. But before you do that, allow me to tell you that this is a very fragile way of doing things, and offers no guarantee. You could, alternatively, investigate the issue deeper:

1. Why is it a problem that the B thread is not started when A releases the resource? Your code should not depend on such logic.
2. Consider using alternative thread synchronization objects like barriers (boost::barrier or <http://linux.die.net/man/3/pthread_barrier_wait> ) instead, if you really need this sort of logic.
3. Investigate if you really need to release the mutex from A at that point - I find the practice of locking and releasing fast a mutex for more than one time a code smell, it usually impacts terribly the performace. See if you can group extraction of data in immutable structures which you can play around with.
4. Ambitious, but try to work without mutexes - use instead lock-free structures and a more functional approach, including using a lot of immutable structures. I often found quite a performance gain from updating my code to not use mutexes (and still work correctly from the mt point of view)