[concurrency-interest] forkjoin.ParallelArray and friends

Doug Lea dl at cs.oswego.edu
Tue Aug 28 06:22:18 EDT 2007

Tim Peierls wrote:

> Seriously, after playing with the current API for a bit, it seems to me 
> that we need a lot more experience using these FJ creatures before 
> trying to device interface-based APIs that are implemented in terms of 
> them. Classes come and go; interfaces are forever.

My take is that premature abstraction into interfaces in libraries
is the worse evil here. Perhaps a good rule of thumb is to postpone
such things for a full release. There are too many examples where
we have had to either throw away good suggestions (createIfAbsent)
or undertake painful retrofitting (NavigableMap) to be very tempted
to relive these sorts of experiences. Especially since the
essential core functionality of ParallelArray is still a bit
tenuous. Random example: Method precumulate is very nichy,
but when you need it, it is very difficult to do yourself
efficiently outside of this class. (For some applications of
precumulate, see  Blelloch's "Prefix Sums and Their Applications"
http://www.cs.cmu.edu/~scandal/alg/scan.html) There may be
others along these lines that we discover as people start
using it. If we had to incrementally add new subinterfaces
here (ParallelArrayWithPrecumulate,
ParallelArrayWithPrecumulateWithFusedMultiplyAdd, etc),
we would soon hit the point of unusability.


More information about the Concurrency-interest mailing list