Date: Wed, 20 Oct 2004 23:22:56 +0000 (UTC) From: Brian Feldman <green@FreeBSD.org> To: ports-committers@FreeBSD.org, cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: ports/java/jdk14 Makefile ports/java/jdk14/files patch-vm::os_bsd.hpp Message-ID: <200410202322.i9KNMuE3092472@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410202322.i9KNMuE3092472>