This Re: Doug Lea's worries about repeated volatile reads:
> For example, in contradiction to V4,
>suppose I want to grab a volatile ref field and hold it in a local to
>avoid multiple barriers while using it to access multiple fields? In
>the absence of ways to express these things, do I just live with the
>fact that I cannot do them?
And Bill's reply:
> If I use the code:
>
> for(int i = 0; i <Foo.a.length; i++)
> total += Foo.a[i];
> Then the code will perform 201 reads of the volatile field a,
> potentially with memory barrier(s) required for each (depending
> on the architecture).
>
> Alternatively, if I use the code:
>
> int [] tmp = Foo.a;
> for(int i = 0; i < tmp.length; i++)
> total += tmp[i]
>
> Then I perform only one read of a volatile and only need one or two
> memory barriers.
In this particular case we can optimize the first example to the
second. Why? There exists a legal execution of the program in which
every single volatile fetch of Foo.a executes before any other node
gets to muck with Foo.a.
Note that this is not true if total is actually a volatile field,
though, so this property is rather fragile.
It is also not true if total is a regular field and volatile stores
are strongly ordered wrt ALL memory stores (condition V6). We're not
keen on that semantics anyhow.
-Jan
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT