Re: JavaMemoryModel: Unsynchronized read as an optimization

From: Robert Munyer (munyer@digi-net.com)
Date: Mon Dec 18 2000 - 14:53:02 EST


On 12/16/00, David Holmes <dholmes@dstc.edu.au> wrote:

> Thread 3, may see helperExists to be either true or false. If it's false
> then it will perform the sync and all is well. If it sees true then it will
> read helper - and as this is the first time it has accessed helper it must
> read it from main memory. Now as the actions on main memory are ordered by
> the locking actions of threads 1 and 2 it follows that helper had to be set
> in main memory before helperExists and so, with a coherent view of main
> memory (as per the current spec), helper can not be null.

I agree with everything you wrote, except possibly that last part in
parentheses. As I understand it, Chapter 17 does not guarantee a coherent
view of main memory. Thread 3 is allowed to load helper and/or its fields
from main memory BEFORE it enters the getHelper method, and then use those
old values after it sees that helperExists is true. That's why the Boolean
configuration parameter is necessary, and why it must not be set to "true"
if the program is running on certain machines (Alpha, and possibly others?).

> Under the revised/proposed specification there will be no guarantee that
> thread 3 sees helper or any of its fields correctly unless it acquires the
> same lock as used by threads 1 and 2 (or else the final/volatile idioms are
> used). The relaxed requirements of the new spec do not require that thread 3
> see main memory the same way as threads 1 and 2 - so even if helperExists is
> seen as true, helper (or its fields) may not be initialised.

If I understand you correctly, it sounds like under the new memory model,
the code above will still work if the Boolean is set to "false" -- but it
won't run as fast as code that has been custom-designed for the new spec by
using "volatile." Note, however, that any such code using volatile would
need to have a similar Boolean configuration parameter, if you want it to be
backward-compatible with JVMs that use the original Chapter 17 memory model.

-- Robert Munyer <munyer@digi-net.com>

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT