Race condition in JV_HASH_SYNCHRONIZATION in libgcj??

Sat Sep 15 01:08:00 GMT 2007

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