26 Jan
2006
26 Jan
'06
3:18 a.m.
On Wed, 2006-01-25 at 22:32 -0500, Lee Revell wrote:
On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote:
Only if you lock/unlock the mutex in an RT aware manner ie; not when you
leave the critical section, but rather when you are done processing and
have met your RT goal. Your high priority thread will then be hanging on
the mutex and can grab the processor again the instant the low priority
thread leaves its critical section, unlocking the mutex.
--
On 1/25/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
On a multiprocessor yes, another thread will be immediately awakened. I
don't think it implies that on a UP the unlocking thread must
immediately schedule away, even if it remains the highest priority
runnable thread (SCHED_FIFO) or still has timeslice left (SCHED_OTHER).
Is pthread_mutex_unlock really not an RT safe operation?
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
In "Programming with POSIX Threads" by David R. Butenhof,
pthread_mutex_unlock is said to do this:
"Unlock a mutex. The mutex becomes unowned. If any threads are
waiting for the mutex, one is awakened..."
Seems to suggest a reschedule. Butenhof worked on the POSIX
standards, so I would consider him an authority.