[concurrency-interest] ForkJoinPool for async http calls?
zhong.j.yu at gmail.com
Thu May 10 23:03:00 EDT 2012
On Thu, May 10, 2012 at 5:00 PM, David Holmes <davidcholmes at aapt.net.au> wrote:
> 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
Yes thread-per-connection doesn't work, today. My question is, could
OS/VM do some optimization to make it work? Or there are reasons
> 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.
Can't all these tricks be done to Thread itself, so that when a thread
waits for an IO completion, it costs very little (much less than what
it costs today).
More information about the Concurrency-interest