Nice to @Share?

[Doug Lea]

On 02/23/10 19:26, Neal Gafter wrote:
>> Than those for local variables. For example, if
>> "this" leaks in a constructor, a reader might see
>> pre-initialized values of a final field. So to
>> verify some property of a use of a final field
>> of some object, you must know something about
>> its constructor. In contrast, properties of
>> local variables are unconditional.
>
> Right, because local variables cannot leak before they are
> initialized...

True at some level, but for a memory model, the
the critical difference is that reading a value written
by another processor entails a cooperative protocol
(thus the possible values read depend on this protocol).
Reading a value written by your own processor does not.
This also shows up at implementation level.
So, for example, writes to final fields may require
memory fence instructions on some processors, and
even reads of them do on others (happily no common
ones though). It is hard to get a handle on such
specs and implementation guidance without the foothold
of locals.

-Doug