Race condition in JV_HASH_SYNCHRONIZATION in libgcj??

[David Daney]

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