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: 
You are inadvertently suggesting that threads should synchronise access to the synchronisation primitive. Mutexes are, as the name suggests, about Mutual Exclusion. They are not designed for control flow. If you want to signal a thread to run from another thread you need to use a synchronisation primitive designed for control flow i.e. a signal.
How do you *know* this:

> 
> While thread A is holding the mutex, thread B attempts to lock it.
>  Since it is held, thread B is suspended.
> 
> 
> 

How do you know thread B is suspended. How do you know that it is not just finished the line of code before trying to grab the lock, but not yet grabbed the lock:

Thread B:

```
x = 17; // is the thread here?
// or here? ('between' lines of code)
mtx.lock();  // or suspended in here?
// how can you tell?

```

You can't tell. At least not in theory.

Thus the order of acquiring the lock is, to the abstract machine (ie the language), not definable.