[concurrency-interest] Parameterized CountedCompleters
Mohan Radhakrishnan
radhakrishnan.mohan at gmail.com
Mon Aug 20 07:35:05 EDT 2012
Hi,
I have some questions from the perspective of a programmer using this. for
general development. Is the copied code the right template for using this ?
The example intends to receive replies from some hosts accordign to a
simple order.
Should this only be used with more number of forked tasks always and not
only a few to take advantage of the original FJ's intention?
from
https://wiki.engr.illinois.edu/download/attachments/202146190/DougLea_juc.pdf?version=1&modificationDate=1342124377000
- The actual (sub)tasks are not recorded; just counts
- But can easily record them yourself
- Applicability
- More well-behaved than RecursiveAction when tasks block ( Is there
more explanation for why they are well behaved ? )
public class CountedCompleters {
public CountedCompleters(){
int procs = 0;
if (procs == 0)
procs = Runtime.getRuntime().availableProcessors();
ForkJoinPool pool = new ForkJoinPool(procs);
pool.invoke( new MasterSocketReceiver ( null ));
System.out.println(pool);
pool.shutdown();
}
static final class Completer extends CountedCompleter<Void> {
Completer() {
super(null, 1);
}
public final void compute() { }
public final void onCompletion(CountedCompleter<?> t) {
System.out.println( "Completed" );
}
}
static final class MasterCompleter extends CountedCompleter<Void> {
MasterCompleter() {
super(null, 1);
}
public final void compute() { tryComplete(); }
}
static final class MasterSocketReceiver extends CountedCompleter<Void> {
Completer c = null;
MasterSocketReceiver(CountedCompleter<?> completer ) {
super( completer );
}
public final void compute() {
MasterSocketReceiver msr = new MasterSocketReceiver( new
MasterCompleter());
msr.fork();
SlaveSocketReceiver ssr = new SlaveSocketReceiver( new
Completer() );
ssr.tryComplete();
System.out.println( "MasterSocketReceiver" );
}
}
static final class SlaveSocketReceiver extends CountedCompleter<Void> {
SlaveSocketReceiver(CountedCompleter<?> completer ) {
super( completer );
}
@Override
public void compute() {
//addToPendingCount(1);
tryComplete();
System.out.println( "SlaveSocketReceiver" );
}
}
}
On Thu, Aug 16, 2012 at 6:12 PM, Doug Lea <dl at cs.oswego.edu> 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 <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120820/514d27af/attachment.html>
More information about the Concurrency-interest
mailing list