[concurrency-interest] preFork() protected method in ForkJoinTask

Tim Peierls tim at peierls.net
Tue Jan 18 08:46:57 EST 2011


I must be missing something. Can't you just have all your tasks extend some
common base that provides enhanced fork and wrapped compute methods?

  public MyTaskBase extends RecursiveAction {
      public MyTaskBase enhancedFork() {
          preFork();
          fork();
          return this;
      }
      protected final void compute() {
          preCompute();
          doCompute();
      }
      protected void preFork() {}
      protected void preCompute() {}
      protected abstract void doCompute();
  }

I don't think the folks who don't want this facility would care to pay for
the extra method calls just to support those who do.

--tim


On Tue, Jan 18, 2011 at 3:55 AM, Antoine CHAMBILLE <ach at quartetfs.com>wrote:

> Could we consider adding a « preFork() » protected method to the
> ForkJoinTask, that would be called by the final fork() method before pushing
> the task in the queue?
>
>
>
> We have at least one use case for that: when some fork join tasks call
> legacy code that rely on thread local contexts it would be nice to subclass
> a fork join task that reads the thread local context during preFork() and
> stores it internally, and then wraps the compute() call by setting that
> context on the actual execution thread. This would also allow the
> application to record statistics comparing the fork time and the computation
> start time for instance.
>
>
>
> -Antoine
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110118/d257b639/attachment.html>


More information about the Concurrency-interest mailing list