Re: [linux-audio-dev] pthread_mutex_unlock

From: Paul Coccoli <pcoccoli@email-addr-hidden>
Date: Thu Jan 26 2006 - 05:27:07 EET

On 1/25/06, Lee Revell <rlrevell@email-addr-hidden-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.
Received on Thu Jan 26 08:15:09 2006

This archive was generated by hypermail 2.1.8 : Thu Jan 26 2006 - 08:15:10 EET