This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Race condition in JV_HASH_SYNCHRONIZATION in libgcj??
- From: Hans Boehm <Hans dot Boehm at hp dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: java at gcc dot gnu dot org, "Boehm, Hans" <hans dot boehm at hp dot com>
- Date: Fri, 14 Sep 2007 21:42:09 -0700 (PDT)
- Subject: Re: Race condition in JV_HASH_SYNCHRONIZATION in libgcj??
- References: <46EB3063.2040808@avtrex.com>
The compare_and_swap just succeeded in overwriting the address field,
which makes us the holder of the lightweight lock on the given
address, and gives us exclusive access to light_thr_id and light_count
for the corresponding hash entry. (The LOCKED bit in the address
field protects other parts of the hash entry, but not those two
fields.)
This code is extremely tricky. It's implementing locks, and hence
doesn't itself follow a standard locking discipline. It's unlikely
there's anything wrong with this particular piece of code, since
it's the most common path.
Hans
On Fri, 14 Sep 2007, David Daney wrote:
In natObject.cc:877 in _Jv_MonitorEnter (jobject obj) we have the following:
.
.
.
if (__builtin_expect(compare_and_swap(&(he -> address),
0, addr),true))
{
JvAssert(he -> light_thr_id == INVALID_THREAD_ID);
JvAssert(he -> light_count == 0);
he -> light_thr_id = self;
// Count fields are set correctly. Heavy_count was also zero,
// but can change asynchronously.
// This path is hopefully both fast and the most common.
LOG(ACQ_LIGHT, addr, self);
return;
}
address = he -> address;
.
.
.
Where 'he->' is used for several different things.
This looks like a race to me. How can we be using 'he -> ' for anything. We
just failed to get a lock on it, how can we assert that it contains anything
useful or consistent across the several uses of it?
David Daney