[concurrency-interest] ParallelArray updates du jour
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
"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
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?
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>
> > 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest