[concurrency-interest] ForkJoinPool for async http calls?

Gregg Wonderly gregg at cytetech.com
Thu May 10 17:58:08 EDT 2012

On 5/10/2012 3:52 PM, Zhong Yu wrote:
> On Thu, May 10, 2012 at 1:37 PM, Roland Kuhn<rk at rkuhn.info>  wrote:
>> Explanation: the flow-block will be transformed by the compiler into continuation-passing style around resultFuture(), effectively breaking it up so that at this point execution is suspended until the result of the future is ready. Imperative coding style, asynchronous execution, profit.
> while that is super cool, it is not as simple and elegant as thread:)
> the reason we do these async stuff is because threads are "expensive".
> but why are threads expensive?

What do you believe is the cost to which expensive is related?  The number one 
issue is that it is more "code", to do "more things".  The question in the 
optimizations of most async systems, is whether or not there is latency in an 
operation which can be hidden by some other action which can be performed in 
parallel.  Latency, the pause or in activity of "preparing" to do something, is 
the primary consideration.  In a completely sequential system, the latency for 
any particular "step", is all the steps that came before it.  Some steps use the 
output of other steps as data, or context.

So, threads are expensive only when the "latency" of using a thread in a 
particular way, can not be "removed" from the system by using another thread to 
do something, unrelated, at the same time.

Practically, thread creation is "expensive", because of the number of 
instructions and implicit "context switches" required to "make" a thread ready 
to use.  Pools of threads, try to optimize this issue, by creating threads 
"once", and then have them ready to execute a task with very little latency 
(just the time it takes to hand the thread a Runnable in a "volatile 
assignment", and then waking the thread so that it can call Runnable.run(), right?

>> Simplicity and elegance are unpopular because they require hard work and
 >> discipline to achieve and education to be appreciated.

Threading in Java, is kind of like the rash of "register" declarations which 
happened in C code in the early days of Unix.  Most compilers would not 
explicitly perform register allocation, and would instead, always use register 
indirect addressing of variables, to read and write them from/to memory.  In 
those days, it was much, much slower to access memory, than a register, as it is 
today, so math programs became extremely fast when you declared variables with 
"register".  But, you had to be able to look at a piece of code, know how many 
register variables you had, and then be able to optimize use of those variables, 
sometimes introducing new blocks with {...} and new register variables, to 
change how registerization was done, while maintaining useful variable names.

Threading is similar.  You need to understand how the code actually works, 
what's async, what has data dependencies, what doesn't, and then how many 
"cores" do you have available, so that you can use them effectively.

Unfortunately, there are perhaps 60%-70% of the "programmers" in the world now, 
who have no idea how a processor and operating system interact with their 
application, so that they can optimize every detail.

Things are so fast now, that for the size of most problems, no one cares.  If I 
need an answer in 5 hours, and you can give me results in 4 hours, I'm probably 
not going to complain much.  But, if my needs suddenly change to 15minutes, then 
the application needs to be optimizable and scalable, to a new level of 
performance, and that's where Dijkstra's comment bares down on reality.

Discipline and Education are required to get there.

Gregg Wonderly

More information about the Concurrency-interest mailing list