Nice to @Share?

[Jesse Kuhnert]

Forgive me for throwing random noise in here, but the basic gist of
things as I understand them is that you would like to be able to add
parallel operations in to some of the core areas like
Collections.sort() / etc in some kind of behind the scenes automated
way and can't really do that if you can't be sure it wouldn't produce
random breakage for people not expecting that behavior at runtime?

If the root issue is that the general safety of variable access is
already something that developers have to purposefully address with
more thread-safe code then anything done here will be sort of un-pure
from a language perspective (unless it solves the root issue, whatever
/ however that is or means. don't yell at me please ;) ) whether it is
addressed via new keywords or @Shared or whatnot. As long as those
doors are being opened, you could also do an even hackier sort of
solution by defining some sort of java.util.concurrent annotation in
general which a developer can decorate their lambda/etc with to let
whatever parallel / thread safety minded api's that are interested
know that they understand the thread safety issues and this one is "ok
to do what you will with" ? At least then the annotation use would
continue to provide meta only information ant not necessarily change
the runtime. (other than possibly being picked up by interested
parallel parties)

At least that could prolong or postpone figuring this issue out more
fully until such point as everyone feels very comfortable with it,
just because it sounds like it's turning out to be a very tough nut to
solve to everyone's satisfaction here.

On Tue, Feb 23, 2010 at 3: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?
>
>> Final variables have guarantees in the memory model too.
>
> Weaker and messier ones.
>
> -Doug
>
>