In the original proposal by Jan-Willem Maessen et al., reading a
volatile acted as an acquire only for the fields/elements of the
object referenced by the value loaded from the volatile. However, it
didn't depend on whether subsequent reads were done through the value
loaded from the volatile, or through another reference that
referenced the same object.
I've corrected a bug in the V4 litmus test that may have been
confusing you. Correction in a separate email.
>I similarly don't understand rationale behind:
>> // Does volatile guarantee fresh values for direct contents of
> > referenced object
Say you have a volatile field containing a reference to a two
dimensional array. If a thread reads that field, it doesn't suffice
to just get correct values of the first level of the array; you want
to get correct values all the way down.
>On the other hand, the equally-excessive V6 is useful since it
>provides a workaround for the fact that you cannot declare array
>elements as volatile. But maybe there ought to instead be a special
>rule for this?
These are options. I'm saying that we ought to enforce all of them,
just that determining which litmus tests are enforced is a way to
characterize a memory model for Java.
V3-V4 handle simple cases like volatile references to arrays of
characters and to objects with non-final/non-volatile scalars. V5 and
V6 handle the nested cases, such as volatile references to
multidimensional arrays and to objects that contains
non-final/non-volatile references to other objects.
I think if we enforce V6, that should also guarantee enforcement of V3-V5.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT