thread scheduling at mutex unlock

[David Xu]

Andriy Gapon wrote:
>
> Maybe. But that's not what I see with my small example program. One 
> thread releases and re-acquires a mutex 10 times in a row while the 
> other doesn't get it a single time.
> I think that there is a very slim chance of a blocked thread 
> preempting a running thread in this circumstances. Especially if 
> execution time between unlock and re-lock is very small.
It does not depends on how many times your thread acquires or 
re-acquires mutex,  or
how small the region the mutex is protecting. as long as current thread 
runs too long,
other threads will have higher priorities and the ownership definitely 
will be transfered,
though there will be some extra context switchings.

> I'd rather prefer to have an option to have FIFO fairness in mutex 
> lock rather than always avoiding context switch at all costs and 
> depending on scheduler to eventually do priority magic.
>
It is better to implement this behavior in your application code,  if it
is implemented in thread library, you still can not control how many
times acquiring and re-acquiring  can be allowed  for a thread without
context switching, a simple FIFO as you said here will cause dreadful
performance problem.