26 Jan
2006
26 Jan
'06
6:54 a.m.
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