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: > > > 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).
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. > 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