[concurrency-interest] Parameterized CountedCompleters

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Aug 28 04:36:09 EDT 2012

Thanks Doug.

I had pulled this update to fjp-trace as well.


On 08/16/2012 04:42 PM, Doug Lea wrote:
> While the most common use cases for CountedCompleters are for
> void actions, there is no good reason to force them to be.
> Several people have wanted to use result-bearing forms, so
> they now support this.
> They now can/should/must be declared as CountedCompleter<T>,
> and you can override method getRawResult to return any appropriate
> result that will be relayed to any call to invoke, join, etc.
> Unlike the case of RecursiveTask<T>, we have no idea how you are
> representing result values, so the protected setRawResult(T x)
> method is by default a no-op. You can override this if desired
> to do some sort of result maintenance, but typically won't.
> This turns out to be a binary-compatible change, so there's
> no need to adjust existing usages immediately. And it is even
> source compatible, although will encounter may "raw type"
> compiler warnings.
> At some point, you'll want to replace
>   class MyCC extends CountedCompleter
> with
>   class MyCC extends CountedCompleter<Void>
> and constructors of form
>   MyCC(CountedCompleter p, ...) { super(p); ...}
> with
>   MyCC(CountedCompleter<?> p, ...) { super(p); ...}
> and similarly for any other methods accepting CountedCompleters).
> This change is now in jsr166y, jsr166e, and j.u.c jars and sources.
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list