[concurrency-interest] jsr166y.forkjoin API comments

David J. Biesack David.Biesack at sas.com
Fri Jan 25 09:56:28 EST 2008


> Date: Thu, 24 Jan 2008 19:25:19 -0500
> From: Doug Lea <dl at cs.oswego.edu>
> CC: concurrency-interest at cs.oswego.edu
> 
> David J. Biesack wrote:
> > Been working with the API more and I have a few more comments/suggestions
> > assembled.
> 
> Thanks! These are great! Please keep them coming! I hope to do
> another renaming etc pass sometime based on the already good
> suggestions stemming from last one.

thank you for the opportunity to observe and comment.
 
> > Having used this a while, I personally don't like the liberal use of
> > "withThis" this and "withThat" throughout the API;
> 
> (Well, except for your suggested use in factories above :-)

I've been corrupted :-)
 
>   rename the
> > resulting ParallelArray*WithBounds, *WithMapping, WithFilter to
> > BoundedParallel*Array, MappedParallel*Array, FilteredParallel*Array. 
> > 
> > FilteredParallelDoubleArray pa = a.filter(myIndexFilter);
> 
> Note that it should be very rare to give a name to (thus mention the
> type of) to this kind of expression though.

The use case I was thinking of was to build a chain of filters/ops and
then save a reference to them.

  FilteredParallelDoubleArray fpa = a
      .filtered(myIndexFilter)
      .mapped(myMap)
      .filtered(mySecondFilter)
      .mapped(mySecondMap)
      .filtered(myThirdFilter);
  
Once this is done, I can obtain the result based on a's current contents:

   ParallelDoubleArray b = fpa.all();

Now I can change the underlying array a:

   a.replaceContents(myCombiner, x); // was: replaceWithMapping

and then extract the new derived array which is based on the modified contents of a :

   ParallelDoubleArray c = fpa.all();

Ditto for reductions, etc. If I'm really careful, I can also modify the filters and mappings between steps
(but certainly not when a step is running).

The hope is that the framework can optimize/combine the steps as necessary (there were earlier mentions of dynamic code generation) and by reusing the intermediate object, can bypass that extra optimization step and object allocations.

It's all the benefits of "rinse, lather, repeat" without having to lather again.

Is this a reasonable use of forkjoin structures?

> -Doug

-- 
David J. Biesack     SAS Institute Inc.
(919) 531-7771       SAS Campus Drive
http://www.sas.com   Cary, NC 27513



More information about the Concurrency-interest mailing list