Parallel-safe lambdas

[Doug Lea]

First some meta-chat: As I stated a few weeks ago, one of the main
thrusts in parallelism these days to make constructions that are
correct and efficient easier to express. Which implies making
incorrect and/or inefficient constructions impossible, or more
difficult, or at least no easier to express than today. Unfortunately,
correctness-enhancing language rules are harder to arrive at
for parallel programs than sequential programs. It would be
great if we had better analogs of static type-safety, definite
assignment, etc that Java does so well to improve quality of
sequential code. Lacking very many of these, we can
focus on constructions that are conditionally OK. As in
calling map, reduce etc with "well-behaved" lambdas,
which allows focusing on what makes them well-behaved,
and then making these cases the easiest to express.
John's sketch of...

> A safe and still useful tradeoff regarding uplevel members (fields, methods) could be this:
>  0. no restrictions on qualified names
>  1. allow unqualified references to immutable variables of all sorts
>    ('unqualified' = 'simple name, no dots')
>    ('immutable' = 'final, or a local implicitly markable as final')
>  2. allow unqualified references to uplevel variables (all sorts) if they are marked @Shared
>  3. allow unqualified references to uplevel methods if they are marked @Shared
>  4. allow unqualified references to uplevel methods if they are "pure" (marked @Pure)
> 

... sounds like it is on the right track to me.


> A lot of this is trying to guess Doug Lea's mind on what he perceives (based on deep experience) leads to racy code.  Doug, does any of this help with those concerns?
> 

(John Rose has been dealing with these issues a long time too.
Several of them were first seen in "C*" -- http://en.wikipedia.org/wiki/C*)

Last, more meta-chat: I honestly do not have an opinion about whether
exploring lambdas with parallel application as use case #1 is the
best plan for evolving Java or even the best plan for exploring
closure-like constructions. It may well be the case that despite
these efforts, other languages running on JVMs will be more sensible
choices as everyday ubiquitous parallelism becomes common. But it
does seem worthwhile to make the very best attempt possible.


-Doug