[linux-audio-dev] pthread_mutex_unlock

[Alfons Adriaensen]

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