Nice to @Share?

Doug Lea dl at cs.oswego.edu
Tue Feb 23 16:11:02 PST 2010


On 02/23/10 18:35, Neal Gafter wrote:
> On Tue, Feb 23, 2010 at 12:57 PM, Doug Lea<dl at cs.oswego.edu>  wrote:
>> On 02/23/10 15:46, Neal Gafter wrote:
>>
>>>   Fields that are not used in lambdas or inner
>>> classes are verifiably and provably not shared between threads.
>>
>> Could you suggest a term and definition of these things so
>> it can be used in your requested clarification of JLS sec 17.4?
>
> Yes: I'd just call them "variables" (17.4.1), and include static
> fields, instance fields, array elements, local variables, formal
> parameters, and exception handler parameters under that term.

I'm running out of ways to say this so will stop after this
last try:

The only way we know to phrase a usable memory ordering spec
entails distinguishing variables that CANNOT be shared
across threads from those that happen not to be
shared in a given program execution. There is nothing
especially Java-ish about this. Specs for other languages
and processors take the same form -- we must be able to
describe states strictly from the point of view of
a given processor/thread, unconditionally with respect
to possible multithreaded program executions.

>>> Final variables have guarantees in the memory model too.
>>
>> Weaker and messier ones.
>
> Weaker and messier than what?

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.

-Doug



More information about the lambda-dev mailing list