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

[Daniel Eischen]

On Sun, 31 Oct 2004, Brian Fundakowski Feldman wrote:

> 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.

We use error check mutexes by default, which is allowed by the
spec, because they come at no cost and it is good to detech
buggy use of mutexes.  When we get a faster (probably using
atomic_cmpset_*, in 6.0), we'll switch the default mutex
over to normal and lose the error checking.

> 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

I've done that.

> 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
  ^^^^^^^  I think you mean EBUSY, no?

> 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?

Because pthread_mutex_trylock() is defined in terms of pthread_mutex_lock()
and pthread_mutex_lock() returns EDEADLK when a thread tries to recursively
lock an error checking mutex.  Since our mutexes are error checking, you
get EDEADLK.

> 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?

I've been running mozilla and other things with libpthread for quite a
while without any problems.  You make it sound like all hell's going
to break loose because of this.  This has been brought up at least
twice before on -threads and we've discussed the behavior.  I've
also sent an email to austin asking for clarification.  And I sent
you follow up email saying the change was OK if you wanted to
limit it to PTHREAD_MUTEX_NORMAL mutexes.

-- 
Dan Eischen