26 Jan
2006
26 Jan
'06
4:17 a.m.
On Wed, Jan 25, 2006 at 10:32:17PM -0500, Lee Revell wrote:
On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote:
If it remains the highest priority one that can be run, clearly it should
just continue. If there is a higher priority one that was waiting for
the mutex, that one should take over - that's the normal priority game.
The only corner case I can imagine is when the contention was between
equal priority threads. But even in that case I'd say that a SCHED_FIFO
thread should run until either it blocks itself, or it is pre-empted
by an higher priority one. So the unlock should have no effect at all.
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.
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?
Depends on your definition of RT-safe. If it amounts to 'the running
thread can't be pre-empted' then clearly the unlock is not safe.
But with that definition _nothing_ is safe - you can be pre-empted at
any time by a higher priority thread that is woken up by an interrupt.
The normal meaning of RT-safe is more like 'doing this will not block
the caller', and in that sense the unlock is RT-safe: when a higher
priority thread takes over, you have not blocked yourself - you are
being pre-empted. That you triggered this yourself doesn't make it
'blocking'.
--
FA