[concurrency-interest] Thread exhaustion

Doug Lea dl at cs.oswego.edu
Wed Apr 7 07:09:05 EDT 2010

Bringing this exchange back to list...

On 04/06/10 06:49, Doug Lea wrote:
> On 04/06/10 03:51, Alexey Kudravtsev wrote:
>> I am now confronting the simple task of mass parallelism that should
>> have been a perfect fit for FJ.
>> So I wrote the program to simulate this:
> Could you send me (off-list) the full version of this so
> I can diagnose?

[Which now works after fixing a usage error. but a few
general issues remain:]

>> Basically, each ParallelArray.apply() task calls join()
>> which blocks the current thread until there are no threads left)
>> If I comment out pool.setMaximumPoolSize() line, it kinda works, but
>> generate excessive number of 'spare' threads.
> (It is rarely a good idea to setMaximumSize in FJ.)

But FJ could cope with this a little better than it does now,
by automatically changing join strategies when max threads are
reached. I'll look into this.

>> P.S. I think the fact that ParallelArray tasks use join() instead of
>> helpJoin() or equivalent makes them not very useful.
>> All of the ParallelArray tasks are independent and therefore are
>> perfectly eligible for helpJoining each other.
> ParallelArray cannot be sure that a computation does
> not itself start another independent FJ computation,
> that would require join, not helpJoin to work well.
> It may be possible to adapt ParallelArray methods to be
> a little smarter about this though.

The main issue here (generally known as "nested parallelism")
is that when each operation of one parallel computation
itself spawns another distinct independent parallel computation,
then it is possible to require a peak usage of O(p-squared)
total threads (where p is parallelism level) in join() version,
or to "bury" O(p-squared) total tasks in the runtime stacks of
the p threads in helpJoin() version. (Or some in-between variant
of these.) In practice, the helpJoin() versions normally need
significantly fewer total resources but in the worst case
will need more and be slower. When arranging FJ computations
manually, you can often avoid worst cases by using helpJoin()
for outer parallelism and join() for inner. If/when lambdas/closures
become available and we reconsider frameworks like ParallelArray,
it be a good idea to explore automating such mechanics.


More information about the Concurrency-interest mailing list