[linux-audio-dev] pthread_mutex_unlock

[James Courtier-Dutton]

Lee Revell wrote:
> One Harold Chu on LKML is insisting that POSIX requires
> pthread_mutex_unlock to reschedule if other threads are waiting on the
> mutex, and that even if the calling thread immediately tries to lock the
> mutex again another thread must get it.  I contend that both of these
> assertions are wrong - first, I just don't read the standard that way,
> and second, it would lead to obviously incorrect behavior - unlocking a
> mutex would no longer be an RT safe operation.  What would be the point
> of trylock() in RT code if unlocking is going to cause a reschedule
> anyway?
>
> Can anyone back me up on this?
>
> Lee
>   
On a uniprocessor machine with two threads.
Thread A waiting for the lock.
Thread B has the lock.
If thread B unlocks the lock, and then locks it again, Thread A is 
unlikely to get a chance to get the lock.
Thread A will only get the lock if the kernel happens to do a task 
switch between Thread B to Thread A.
If one wants B to release the lock, and give Thread A a chance to grab 
it, Thread B will have to co-operatively trigger the kernel to task 
switch to Thread A. Methods for Thread B to trigger the kernel to task 
switch to Thread A is not well defined, as it is just as likely that 
some other process will get the task switch, and not Thread A at all.
The reliable way to fix this problem is to keep in mind that 
pthread_mutex_lock/unlock is NOT FAIR. This results in one just 
designing one's software differently. The Linux kernel developers all 
know this fact, and have manged to always provide a solution that works.
This was discussed during the KS, and the performance hit from making 
things "fair" is too high to bother trying to implement it.

James