[linux-audio-dev] pthread_mutex_unlock

[Jens M Andreasen]

On Wed, 2006-01-25 at 22:32 -0500, Lee Revell wrote:
> 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? 
> 

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.

--