> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: RV-Predict bugs

> st_200 is non-volatile

> L1 if (st_200 == null ) {
> L2    st_200 = sm.getString("sc.200");
> L3 }
> L4 return st_200;

> Ln=Line n
> Tx=Thread x
> Rn=Read at line n
> Wn=Write at line n

> So T2 has two reads, T2R1 and T2R4.

> Depending on the value read for T2R1 there may be a write at T2W2.
> If there is a write there is a happens before relationship between T2R1
> and T2R4.

There is also a happens-before relationship between T2R1 and T2R4 due to JLS 
Section 14.2 (Blocks), not Section 17.4 (Memory Model).  The JMM cannot be 
considered in a vacuum.

> Consider the following sequence
> T2R4 (out of order read returns null)
> T1R1 (returns null)
> T1W2 (writes non-null value)
> T1R4 (reads new non-null value)
> T2R1 (reads new non-null value)

The above is not permitted due to Section 14.2 (although it would be by 17.4).  
The compiler must not move T2R4 in front of T2R1 because of the potential of 
T2W2 occurring.  Correct operation is dependent on the CPU observing the same 
value for T2R1 and T2R4, which is implemented in all current hardware I'm aware 
of by not permitting reordering of accesses to the same memory location (e.g., 
see Chapter 8 of the Intel 64 Architecture SDM, Volume 3 - System Programming 
Guide).  Such accesses are usually just combined when they occur.

> Because T2R1 reads a non-null value there is no write in T2.

> Therefore there is no happens-before relationship between T2R1 and T2R4
> because there is no intervening write in that thread (the write happens
> in T1).
> Therefore the re-ordering is allowed to happen.
> And we get the unexpected result.

If the JMM were the only controlling specification, that would be true.  Since 
the JVM must also conform to Section 14, the happens-before order exists, and 
we don't have a problem.

> The write at T1W2 is sufficient to enforce the happens before
> relationship between T2R1 and T2R4.

Yes, the potential of the write occurring is enough.

> In which case what is the point of volatile? What do I gain by using it?

In this particular case, nothing.  Volatile is often useful inside a loop where 
you want to make sure that the reference is not hoisted outside of the loop, 
effectively becoming a constant for the duration of the loop.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to