The BSD patchset for the Sun JDK modeled its thread behavior mostly after

existing the Solaris base, and similarly to what happened with NSPR, made
a bad assumption on undefined behavior.  This broke locking in various
places in Java, for example, causing the the debugging support to be
totally broken.  It is worth someone who knows the Java codebase taking
a look to see what other things could have been broken by this on
FreeBSD 5.x+.

The assumption is that pthread_mutex_trylock(3) on a default-type
mutex will fail with EBUSY.  This assumption is wrong for our
libpthread, which returns EDEADLK if the owner thread is trying to
acquire the mutex again with trylock.  The behavior of performing a
locking operation on a self-locked default-type mutex is explicitly
undefined for pthread_mutex_lock(3).

The POSIX specification is still not very clear.  It defines
pthread_mutex_trylock(3) in terms of pthread_mutex_lock(3) yet
does not say what the defined behavior should be for a self-locked
pthread_mutex_trylock(3) for any of the various mutex types, so it is
ambiguous whether the result is clearly undefined or clearly to return
EBUSY.

It is a one line change whether or not to make libpthread return
EDEADLK in this case, where it seems that most implementations do not.

Reference:	http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html

0 files changed, 0 insertions, 0 deletions