Nice to @Share?
Neal Gafter
neal at gafter.com
Tue Feb 23 18:25:26 PST 2010
On Tue, Feb 23, 2010 at 5:09 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.
OK, I can certainly see that 17.5.1 as written only works for instance
fields (and not locals). The corresponding rule for a local would be
that the write executed by the method in which the local variable is
declared happens-before any reads in other threads. I had hoped to
infer that from the transitive closure of the definite assignment rule
for the local happening before the anonymous instance is created (due
to definite assignment rules) and the write to a final field
(capturing the local in the anonymous instance) following that in the
same thread, combined with the happens-before relationship defined by
17.5.1 applied to that field. Unfortunately, the JLS's specification
for how constructors of anonymous instances work (15.9.5.1) is not
correct in the presence of captured locals.
Still, I think it would be better to fix the JLS bugs that prevent
this logic from working rather than adding axioms that should be
consequences of existing rules.
More information about the lambda-dev
mailing list