[concurrency-interest] Re: leaders/followers pattern
dholmes at dltech.com.au
Wed Jun 8 19:34:14 EDT 2005
> 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
> handles it.
> 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.
The advantage of the pool based design is that all the bits are present in
java.util.concurrent, and all thread pool management is handled for you. In
the leader/follower pattern your "pool" is simpler in that all threads just
wait on a given object until notified, but then you have the responsibility
for all thread management: how many to create, when to create, do they die
when idle, what happens when you run out of threads etc etc. All that
functionality is built in to the existing executor services: you just need
to decide on what policy you want. Of course you could use an executor in
leader/follower too: the leader submits a task that simply waits for the
next event then submits a similar task.
Personally I like to keep thread roles distinct: an event demultiplexor or
an event processor.
More information about the Concurrency-interest