[linux-audio-dev] pthread_mutex_unlock

[Lee Revell]

On Wed, 2006-01-25 at 22:27 -0500, Paul Coccoli wrote:
> On 1/25/06, Lee Revell <rlrevell at joe-job.com> 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
> >
> >
> 
> 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? 

Lee