[concurrency-interest] jsr166y Parallel*Array withMapping/withFilter chaining

David J. Biesack David.Biesack at sas.com
Wed Jan 23 16:07:53 EST 2008


I find that I cannot do the following

   public ParallelDoubleArray chain(int size) {
        return = ParallelDoubleArray.create(size, myForkJoinExecutor)
         .replaceWithGeneratedValue(myGenerator)
         .withMapping(myMapping)
         .withFilter(myFilter)
         .withMapping(myOtherMapping).all();
    }

Instead, I am forced to construct an intermediate ParallelArray because withMapping returns a ParallelDoubleArrayWithMapping and that class does not provide a withFilter(Ops.DoublePredicate) method.

    public ParallelDoubleArray chain(int size) {
        ParallelDoubleArray intermediate;
        intermediate = ParallelDoubleArray.create(size, myForkJoinExecutor)
         .replaceWithGeneratedValue(myGenerator)
         .withMapping(myMapping).all();
         intermediate = intermediate.withFilter(myFilter)
         .withMapping(myOtherMapping).all();
        return intermediate;
    }

It appears to force premature allocation of the intermediate buffer and consequently higher intermediate memory consumption, a concern for larger arrays.

Is this by design (or necessity), or an accidental omission? I suppose I can see how a filter normally changes the number of elements and thus must be run completely before applying a next step (mapping), but even so, it would be nice for the framework to internalize this so that client code is not forced to express possibly inefficient paths that prevent future optimization.

-- 
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