[concurrency-interest] ParallelArray updates du jour

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Mon Jan 21 06:44:43 EST 2008


Thank you for the clarification!

It appears that one of the main characteristics required of the sub-tasks is
their non-blocking nature. The doc for FJTask distinguishes three types of
blocking:

"The computation defined in the compute method should not in general perform
any other form of blocking synchronization, should not perform IO, and
should be independent of other tasks."

The kind of blocking which I feel could be more closely defined is: IO.
Naively, I would define IO as operations involving reading from, or writing
to a physical device. Is main system memory (RAM) to be considered a
physical device in this context? If so, I assume FJTask instances must be
fine-grained enough for the working set of any individual FJTask instance
to  fit into the on-CPU cache of the processor the FJTask starts being
scheduled on.

A corollary requirement is then that FJTask instances should complete
quickly enough so as to reduce the probability of
(a) the OS "migrating the instance" to another CPU due to rescheduling
(b) the instance being rescheduled in general - in case the on-CPU cache is
not large enough to hold the working sets of multiple instances.

Is this correct?

Thanks
Peter

On Jan 20, 2008 9:28 PM, Tim Peierls <tim at peierls.net> wrote:

> On Jan 18, 2008 6:25 PM, Peter Kovacs <peter.kovacs.1.0rc at gmail.com>
> wrote:
>
> > In more concrete terms: I feel I could make good use of a high-level
> > explanation of how the new API is helping me (the "concurrency dummy") solve
> > problems more easily and more safely than the already existing concurrency
> > infrastructure.
> >
>
> I think the question is: For what problems is this new API better-suited
> than existing tools? The class javadocs for ForkJoinTask, RecursiveAction,
> and RecursiveTask sort of answer this.
>
>
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/forkjoin/ForkJoinTask.html
>
> Crude paraphrase: Use fork-join when you can express a big computation as
> lots of fine-grained tasks that can wait for other such tasks to complete
> but otherwise never (or very rarely) block. And don't expect too much from
> this stuff on a uniprocessor.
>
> For example, fork-join would not work well for full request-to-response
> handling in a server (use existing tools for that), but it might be useful
> to implement a compute-bound stage of such a server.
>
>
>  (I am not even sure which is the head and which is the tail of this API
> > beast.)
> >
>
> One thing that might not be clear from the javadocs is that the
> ParallelArray stuff is written on top of the fork-join stuff; it's an
> application of fork-join. It's a little confusing because everything is in
> one package currently.
>
> --tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080121/89d086f8/attachment-0001.html 


More information about the Concurrency-interest mailing list