pthread_mutex_trylock() should never block

[Daniel Eischen]

On Thu, 29 Jan 2004, Mike Makonnen wrote:

> On Wed, Jan 28, 2004 at 12:01:27PM -0500, Daniel Eischen wrote:
> > On Wed, 28 Jan 2004, Mike Makonnen wrote:
> > 
> > > On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote:
> > > > 
> > > > The man page may not mention it, and that may be a bug, but I
> > > > think a pthread_mutex_trylock() on a non-recursive mutex is allowed
> > > > to return EDEADLK.
> > > > 
> > > >   http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html
> > > > 
> > > >   If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error
> > > >   checking shall be provided. If a thread attempts to relock a
> > > >   mutex that it has already locked, an error shall be returned.
> > > >   If a thread attempts to unlock a mutex that it has not locked
> > > >   or a mutex which is unlocked, an error shall be returned.
> > > > 
> > > >   ...
> > > 
> > > If you look further down in the spec you will see:
> > > 
> > >    The pthread_mutex_trylock() function shall be equivalent to
> > >    pthread_mutex_lock(), except that if the mutex object referenced
> > >    by mutex is currently locked (by any thread, including
> > >    the current thread), the call shall return immediately...
> > 
> > Yes, but the implementation has to use internal locks to
> > keep the mutex in a consistent state.  There is no problem
> > here.
> 
> Apologies, I was commenting on the EDEADLK vs. EBUSY issue, not the "is an
> internal lock allowed to block in pthread_mutex_trylock" issue. I should
> have also explained better instead of just throwing out the quote.
> 
> EDEADLK is returned by pthread_mutex_lock() only on error
> checking mutexes that would otherwise deadlock if they were not error
> checking. Since pthread_mutex_trylock() must return immediately whether
> the mutex is error-checking or not, I think for consistency sake it should
> return EBUSY regardless of what type of mutex it is operating on. Also,
> the 'ERRORS' section lists EDEADLK as a _possible_ return value only for
> pthread_mutex_lock().

I looked at "pthread_mutex_trylock() function shall be equivalent to
pthread_mutex_lock()" and inferred that it even meant returned
errors should be equivalent.

> I'm not a standards expert but I think it is permissable for an
> implementation to return EDEADLK from pthread_mutex_trylock(). However,
> I think it's better to always return EBUSY, rather than EDEADLK in
> some cases and EBUSY in others. 

Well, anything that relies on pthread_mutex_trylock() != EBUSY
to mean that the function worked is broken (clearly 0 is the
only return that means success).  And if the application wants
to know if the current thread has the mutex locked, then
returning EBUSY doesn't tell you anything, whereas EDEADLK
does.  Yeah, I know, applications should keep track of which
mutexes they have locked!

-- 
Dan Eischen