[concurrency-interest] Re: leaders/followers pattern
dawidk at mathcs.emory.edu
Wed Jun 8 23:54:38 EDT 2005
David Holmes wrote:
>> Actually I meant the following pattern.
>>1. Leader thread waits for event on any handle in its handle set
>>2. When event is detected, a follower is promoted to leader
>>3. Uses event handler to process event.Rejoins the thread pool
>>when processing finishes (as either leader or follower)
>>So instead of giving the task to another thread in the pool, the leader
>>This is supposed to reduce context switching. Are there any
>>implementations of this ? I am looking at java.util.concurrent now. Can we
>>if we want to reduce context switching ?
>I don't see any advantage of the above "pattern" with the more usual/common
>design where a single thread handles the event demultiplexing and then
>"pushes" the event into a work queue for processing by a thread pool - ie
>the event is submitted to the pool as a task. In abstract terms the number
>of context switches are the same - both designs require the event
>demultiplexing thread to cause another thread to wake: either to become the
>new demultiplexor; or to process the event.
Actually I am with Mohan on this one. The point is to reduce response
latency, i.e. eliminate the context switch on the path between receiving
request (usually on the socket) and sending back the response.
Underlying assumption is that the requests are relatively infrequent
(i.e. typically less frequent than preemptive context switches) but
non-uniform in the required processing time. Some may take long time, so
you want to have concurrency. On the other hand, many are very short,
e.g. of the order of microseconds, and for those you want to minimize
latency. Context switching overhead in Java on Linux with 2.4 kernel, on
2.4 GHz P4 machine is about 100 microseconds, so it can significantly
contribute to the latency in this case.
More information about the Concurrency-interest