[concurrency-interest] ForkJoinPool for async http calls?

David Holmes davidcholmes at aapt.net.au
Thu May 10 23:12:32 EDT 2012

Zhong Yu writes:
> 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
> prohibiting that?

Could you design an OS where threads are less resource intensive than they
are today in existing OS? Sure, but along the way you will be making various
trade-offs. Could today's OS thread support be more efficient? Probably, but
these are exceedingly complex systems with a lot of historical baggage.

> > 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).

Threads don't have work queues so I'm not sure what you mean really.

What's the cost of "waiting for an IO completion"?

These questions are just too general - there's no way to answer them in a
general way.


More information about the Concurrency-interest mailing list