This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Race condition in JV_HASH_SYNCHRONIZATION in libgcj??
- From: David Daney <ddaney at avtrex dot com>
- To: java at gcc dot gnu dot org
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>
- Date: Fri, 14 Sep 2007 18:07:47 -0700
- Subject: Race condition in JV_HASH_SYNCHRONIZATION in libgcj??
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