[concurrency-interest] Parameterized CountedCompleters

[Mohan Radhakrishnan]

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>