Nice to @Share?

[Doug Lea]

On 02/23/10 12:03, Neal Gafter wrote:
> On Tue, Feb 23, 2010 at 3:17 AM, Alex Buckley<Alex.Buckley at sun.com>  wrote:
>> Consider also JLS3 17.4.1: "Local variables ... are never shared between
>> threads and are unaffected by the memory model."
>
> On second thought, that sentence appears to be a spec bug.  Local
> variables can indeed be shared between threads, though today that
> requires the variable be final and used in an inner class.  The memory
> model doesn't say what the behavior should be (another bug), but I
> expect section 17.5 should be generalized to talk about "final
> variables" instead of just "final fields".  Otherwise the JLS is
> simply not correct today.
>

One cannot define a processor- or language-level memory
model without reference to a category of variables that are
intrinsically local to a processor/thread. Without this,
the memory model would need to be defined at least one level
lower, via bytecode or register mappings, which would not
be doing anyone a favor. So if the syntactic category
of "local variables" isn't sufficiently precise, the
JLS should be clarified. One alternative is to document
the translation scheme for introducing new variables in
inner classes with capturing values, in which
case case you wouldn't need to call these "locals", and
could deduce their safety by virtue of the other JMM rules.

Of course, the absolute knowledge that a local is in fact
thread-private is critical in implementing many concurrent
algorithms. It is frightening to contemplate how to
program  without this.

-Doug