cvs commit: src/lib/libpthread/thread thr_mutex.c

[Brian Fundakowski Feldman]

On Sun, Oct 31, 2004 at 06:19:45AM -0500, Daniel Eischen wrote:
> On Sun, 31 Oct 2004, Brian Feldman wrote:
> 
> > green       2004-10-31 05:03:50 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     lib/libpthread/thread thr_mutex.c
> >   Log:
> >   Make pthread_mutex_trylock(3) return EBUSY on failure, as all software
> >   packages expect and seems to be most correct according to the slightly-
> >   ambiguous standards.
> >
> >   MFC after:              1 month
> >   Corroborated by:        POSIX <http://tinyurl.com/4uvub>
> >   Reviewed by:            silence on threads@
> 
> I never saw this, and there has been a couple of long threads about
> it.  The current behavior was deemed correct especially since default
> mutexes are error check mutexes.  The rationale is that it provides a way
> for a thread to tell if it owns the mutex if EDEADLK is returned.
> 
> Please back out and sorry for not seeing a posting on -threads.

What is your rationale for choosing a very, very loose interpretation
that deliberately acts entirely differently from essentially every other
implementation, and is proven to be repeated cause for breakage in
software because of the gratuitous differences.

I am not even going to bother going into our choice of PTHREAD_MUTEX_DEFAULT
as a _#define_ for PTHREAD_MUTEX_ERRORCHECK.  Just read the standard and
point out, after reading the entire thing, then re-reading the ERRORS
section again and again, where it says pthread_mutex_trylock(3) can return
EDEADLK.  Notice how every one of those four functions is explicitly broken
out into which error returns it supports.

After further review, I can't possibly see how the behavior you chose to
use is allowed by a reasonable interpretation of the standard.  Have you
consulted any standards@ people?  Where did you get this interpretation?

If you want to back this out and make dead certain to error on the side
of incompatibility, go ahead and do it yourself.  You're not the one that
has spent the hours finding this problem in existing pthreads applications,
and you're probably not going to find and fix all the rest of the cases
of incompatibility this choice makes.  It really doesn't effect you at all,
does it?

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\