Date: Wed, 20 Oct 2004 19:29:38 -0400 From: Brian Fundakowski Feldman <green@FreeBSD.org> To: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: cvs commit: ports/java/jdk14 Makefile ports/java/jdk14/files patch-vm::os_bsd.hpp Message-ID: <20041020232938.GJ1072@green.homeunix.org> In-Reply-To: <200410202322.i9KNMuE3092472@repoman.freebsd.org> References: <200410202322.i9KNMuE3092472@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041020232938.GJ1072>