Parallel-safe lambdas

[Rémi Forax]

Le 11/02/2010 11:12, Mark Thornton a écrit :
> Olivier Allouch wrote:
>    
>> Ouch !
>>
>> I, like Stephen Colebourne, am surprised. I thought the goal was to add
>> closures to the language, not to a single library.
>>
>>      
> I'm not sure why you are surprised given that the closures exercise was
> restarted with this:
> http://blogs.sun.com/mr/entry/closures
> The motivation is clearly to aid use of parallelism. Now this doesn't
> mean that many ordinary programmers will be writing parallel code, but
> that more API may use parallel implementations. So if someone uses
> Collections.sort or Arrays.sort, the implementation may be parallel if
> the size warrants it.
>
> For API taking lambda parameters it would be desireable to be able to
> mark such parameters as 'restricted' in some way. Or perhaps have
> lambdas that satisfy appropriate concurrency rules implement some marker
> interface. The API could then use a parallel implementation for such
> marked lambdas. The user can then be largely oblivious to the
> concurrency issues, while leaving the likes of Doug Lea to provide high
> performance implementations.
>
> Mark Thornton
>    

Mark, I don't think we need to distinguish between restricted
and unrestricted closure.
I prefer the idea to avoid shared states to let the implementation
choose if the code has to be run parallel or not.

By example, using the Apache collections, you can write:
shared int i=0;
List<String> list =
CollectionsUtils.forAllDo(list, #(String s) {
   if (s.startsWith("foo"))
     i++;
}):

But this code can't run in parallel.

It's better to use a kind of map/reduce:
int i = Collections.mapReduce(list,
    #(String s) (s.startsWith("foo")?1:0),
    #(int value, int value2) ( value + value2));


In my opinion, lambdas should be restricted to only access
final local variables and final fields.
But perhaps have seen too much talks of Erik Meijer :)

Rémi