Double check locking

[Bryce McKinlay]

Boehm, Hans wrote:

>To clarify the issue:
>
>My impression is that we are careful in the initialization code that the actual initialization precedes the setting of the klass->state.  That's fairly cheap to get right anyway.  The question is if in code like
>
>	(1) if (klass -> state != JV_STATE_DONE) ...
>	(2) read initialized data from klass
>
>the read of the state variable in (1) is guaranteed to precede the reads in (2).  I believe the answer for esssentially all modern architectures is "no".  (See for example ftp://download.intel.com/design/Pentium4/manuals/24547207.pdf, S 7.2.2 "1. Reads can be carried out speculatively and in any order. ...")
>

You are quite right. I completely forgot about the ordering of reads, so 
what I said yesterday was wrong. A read barrier is required before 
reading klass->state.

I guess that the best way of implementing this is to add support in the 
back end for "java volatile" MEMs. Memory barriers for reads and writes 
to java volatiles would be added automatically on platforms that need it.

>The right way to handle this is almost certainly to treat "klass -> state" as a Java volatile, and get Java volatiles to work correctly, as in the new proposed Java memory model.  Volatile reads should enforce ordering between that read and subsequent memory accesses.  On Pentium 4, I believe this requires a memory barrier. 
>

This means the current hash synchronization code is not safe on Pentium 
4, right? Our release_set and write_barrier are implemented as no-ops 
for x86. How does one implement a write barrier for x86?

regards

Bryce.