[concurrency-interest] ForkJoinPool for async http calls?

David Holmes davidcholmes at aapt.net.au
Thu May 10 18:00:36 EDT 2012

Zhong Yu writes:
> the reason we do these async stuff is because threads are "expensive".
> but why are threads expensive?

"expensive" may be the wrong term. There are different costs associated with
using threads (memory and other resources to be allocated; cost of context
switching and communicating between threads) and in different contexts these
costs can become greater than what can reasonably be supported. For example,
thread-per-connection designs don't scale to thousands of connections
because, generally speaking, you can't create thousands of threads. So you
use alternative designs to alleviate pressure on the "resource" you are
having issues with - be that memory or computation costs.

ForkJoin based recursive decomposition wins over direct thread-based
recursive decomposition because it has already optimized for the bottlenecks
that will occur in such designs. Per-thread queues remove a single point of
contention. Work-stealing tries to minimize idle threads and context
switches by keeping threads that are logically blocked waiting for a result,
actively participating in the computation that may ultimately lead to that
result. The implementation of work-stealing (take from the head, steal from
the tail) is also designed to minimize contention.


More information about the Concurrency-interest mailing list