pthread_mutex_trylock() "blocks" when it should not

[Paul Davis]

The man page for pthread_mutex_trylock() says:

       pthread_mutex_trylock     behaves      identically      to
       pthread_mutex_lock,  except  that  it  does  not block the
       calling thread if the mutex is already locked  by  another
       thread (or by the calling thread in the case of a ``fast''
       mutex). Instead, pthread_mutex_trylock returns immediately
       with the error code EBUSY.
 
A common interpretation of this is that pthread_mutex_trylock() does
not yield control of the processor *under any circumstances*.

However, in the code for pthread_mutex_trylock(), an attempt is made
to acquire the "spinlock" for the mutex. If this fails, we call
sched_yield(). This is not "blocking" in the classic sense, but it
definitely yields control of the processor, and makes the call useless
to real-time software that cannot afford the scheduling delay that
this causes. Several of us working on real time audio applications 
for audio have recently encountered this issue, and its a very
problematic one for us. 

I would appreciate it if someone could:
  
   * clarify the semantics of pthread_mutex_trylock() to state
       clearly if a call to sched_yield() is "legal". the proposed
       semantics would be:

       ----------------------------------------------------------
       pthread_mutex_trylock     behaves      identically      to
       pthread_mutex_lock,  except  that  it  does  not block the
       calling thread if the mutex is already locked  by  another
       thread (or by the calling thread in the case of a ``fast''
       mutex). 

>>     It will also not block if it the status of the mutex
>>     cannot be determined without yielding control of the processor.

       Instead, pthread_mutex_trylock returns immediately
       with the error code EBUSY.
       ----------------------------------------------------------
 
AND/OR

   * fix this bug (the patch is about 3 lines long, but since
       i don't have glibc source to hand (only linuxthreads
       itself, from when it was a standalone package), i can't
       supply it here. you just need a nonblocking version of the 
       "acquire" function that returns the value of testandset(),
       and pthread_mutex_trylock() should return EBUSY if its
       not zero.

Paul Davis <address@hidden>                                 Bala Cynwyd, PA, USA
Linux Audio Systems                                             610-667-4807
----------------------------------------------------------------------------
hybrid rather than pure; compromising rather than clean;
distorted rather than straightforward; ambiguous rather than
articulated; both-and rather than either-or; the difficult
unity of inclusion rather than the easy unity of exclusion.   Robert Venturi
----------------------------------------------------------------------------