Re: [linux-audio-dev] pthread_mutex_unlock

From: James Courtier-Dutton <James@email-addr-hidden>
Date: Thu Jan 26 2006 - 13:54:49 EET

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
Received on Thu Jan 26 16:15:08 2006

This archive was generated by hypermail 2.1.8 : Thu Jan 26 2006 - 16:15:08 EET