cvs commit: ports/java/jdk14 Makefile ports/java/jdk14/files patch-vm::os_bsd.hpp

[Brian Fundakowski Feldman]

On Wed, Oct 20, 2004 at 11:22:56PM +0000, Brian Feldman wrote:
> green       2004-10-20 23:22:56 UTC
> 
>   FreeBSD ports repository
> 
>   Modified files:
>     java/jdk14           Makefile 
>   Added files:
>     java/jdk14/files     patch-vm::os_bsd.hpp 
>   Log:
>   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
>   
>   Revision  Changes    Path
>   1.81      +1 -1      ports/java/jdk14/Makefile
>   1.1       +13 -0     ports/java/jdk14/files/patch-vm::os_bsd.hpp (new)

It would be reeeeeeally nice if we could decide whether to change
this behavior before 5.3-RELEASE, since it's a single-liner and is
continually biting people.

My opinion is that POSIX "wants" you to return EBUSY if you're going
to do any error checking at all in pthread_mutex_trylock(3).

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