Preparing for the 0.2 draft

[John Rose]

On Feb 2, 2010, at 3:55 AM, Doug Lea wrote:

> those few parallel languages that include some form
> of lambda/closure (including X10 and Fortress) do not
> hoist scopes.

And, at present, Java hoists scopes (into inner classes) in a non-racy manner.  This is a direct and intentional result of the 'must be final' rule.  Alex is not yet proposing to weaken that rule, except to add 'as if' to the finality requirement.

If there's a problem, it is with the basic Java object model, which does not externally distinguish "pure" Java objects from normal ones.  Sure, you can define pure ones by using blank finals, etc.  But you cannot make an API that only accepts pure objects.  I think this problem should be solved, but it's not specifically a lambda-dev problem.

Are you suggesting that lambdas should wait for a solution to the problem of checking object purity?  That seems impractical.  Maybe there is some compromise measure to be taken, to "discourage" use of impure objects?  Perhaps we can have an advisory annotation that "certifies" objects as safe for parallel processing, and do some checks to warn when passing uncertified references (directly or indirectly) to a parallel loop?

In any case, scope capture per se is a red herring.  Any bulk processing or FJ API is going to have to pass request parameters into the little bits of code that actually run in parallel.  If *any* of those parameters are general Java references, impure objects can and will introduce raciness.  But (until the 'must be final' rule is relaxed) scope capture per se will *never* introduce raciness.

-- John