[concurrency-interest] ParallelArray updates du jour

Doug Lea dl at cs.oswego.edu
Mon Jan 21 08:32:03 EST 2008

> "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?

More or less. Like all lightweight-task frameworks, FJ does
not explicitly cope with blocked IO: If a worker thread
blocks on IO, then (1) it is not available to help process
other tasks (2) Other worker threads waiting for the task
to complete (i.e., to join it) may run out of work and waste
CPU cycles. Neither of these issues completely eliminates
potential use, but they do require a lot of explicit care.
For example, you could place tasks that may experience
sustained blockages in their own small ForkJoinPools.
(The fortress folks do something along these lines
mapping fortress "fair" threads onto forkjoin.) You
can also dynamically increase worker pool sizes (we
have methods to do this) when blockages may occur.
All in all though, the reason for the restrictions and
advice are that we do not have good automated support
for these kinds of cases, and don't yet know of the
best practices, or whether it is a good idea at all.


More information about the Concurrency-interest mailing list