Leader/Followers

 This article outlined a global view of the Leader/Followers pattern  in POSA2 as my reading note.

The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, and process service requests that occur on the event sources.

Design a thread pool mechanism that allows multiple threads to coordinate themselves and protect critical sections while detecting, demultiplexing, dispatching, and processing events. In this mechanism, allow one thread at a time - the leader - to wait for an event to occur on a set of event sources. Meanwhile, other threads - the followers - can queue up waiting their turn to become  the leader. After the current leader thread detects an event from the event source set, it first promotes a follower thread to become  the new leader. It then plays the role of a processing thread, which demultiplexes and dispatches the event to a designated event handler that performs application-specific event handling in the processing thread. Multiple processing threads can handle events concurrently while the current leader thread waits for new events on the set of event sources shared by the threads. After handling its event, a processing thread reverts to a follower role and waits  to become the leader thread again.

There are five key participants in the Leader/Followers pattern:

Handles: Handles are provided by operating systems to identify event sources, such as network connections or open files, that can generate and queue events. Events can originate from external sources, such as CONNECT events or READ events sent to a service from clients, or internal sources, such as time-outs.

Handle set: A handle set is collection of handles that can be used to wait for one or more events to occur on handles in the set. A handle set returns to its caller when it is possible to initiate an operation on a handle in the set without the operation blocking.

Event handler: An event handler specifies an interface consisting of one or more hook methods. These methods represent the set of operations available to process application-specific events that occur on handle(s) serviced by an event handler.

Concrete event handlers: Concrete event handlers specialize the event handler and implement a specific service that the application  offers. In particular, concrete event handlers implement the hook method(s) responsible for processing events received from a handle.

Thread pool: At the heart of the Leader/Followers pattern is a thread pool, which is a group of threads that share a synchronizer,  such as a semaphore or condition variable, and implement a protocol for coordinating their transition between various roles. One or more threads play the follower role and queue up on the thread pool synchronizer waiting to play the leader role. One of these threads is selected to be the leader, which waits for an event to occur on any handle in its handle set. When an event occurs, the current leader thread promotes a follower thread to become the new leader. The original leader then concurrently plays the role of a processing thread, which demultiplexes that event from the handle set to an appropriate event handler and dispatches the handler's hook method to handle the event. After a processing thread is finished handling an event, it returns to playing the role of a follower thread and waits on the thread pool synchronizer  for its turn to become the leader thread again.