Serial Wait State Pattern
Realtime software sometimes involves handling serial interactions with multiple entities. A request is sent to an entity to initiate an operation, its response is awaited and then on receipt of response, another request is sent to the next entity and this sequence continues until response has been received from the last entity in the sequence. Further action can be initiated only after response message has been received from the last entity.
Serial Wait state pattern handles such scenarios. Serial Wait state pattern is simpler to implement than Parallel Wait state pattern. Also, it is easier to isolate faults and initiate corrective action in Serial Wait state pattern since at any given time, request response handshake is being performed only with one entity.
The figure below shows a typical serial operation. Here A initiates a serial operation by sending a request to B. When B responds back to A, request is sent to C. Similarly, when C responds back to A, request is sent to D to perform the operation and respond back to A.
Intent
The main intention here is to initiate similar activity on multiple entities in serial. Since activities are initiated in serial, the time taken to perform the task increases with the number of entities involved in the interaction. When the number of entities involved is too large and the operation is time intensive, Parallel Wait state pattern should be preferred over Serial Wait state pattern.
Serial Wait state pattern is suitable for its simplicity in design only when the number of entities involved is small. Also, if each interaction is resource intensive, then Parallel Wait state pattern will lead to loading the system with multiple interactions running in parallel. In such cases, Serial Wait state pattern is a better option as it allows only one resource intensive operation to be active at any given time.
Also Known As
- Sequence Action State Pattern
- Serial Interaction
Motivation
Main motivation to use Serial Wait State pattern is to have a better control over operations with multiple entities by allowing only one operation at a time. In such designs, fault diagnosis is straightforward. However, such designs do not scale very well with the increase in number of entities.
Applicability
The Serial Wait State pattern can be used wherever an operation needs to be performed on multiple entities and each operation is resource intensive, thus not suitable for parallel operation.
Serial operations are generally simpler to implement and debug than parallel operations. Thus they are a first choice of designers. Parallel operation is often viewed as an optimization that can be carried out for serial operations that turn out to be time intensive.
Structure
This pattern consists of the following event handlers:
- Serial Message Sending Routine: This routine sends message to the next entity and starts a timer to keep track of its response. It reports successful completion of serial operation after the serial response handler receives the response from the last entity.
- Serial Response Handler: This handler receives the response message and responds to serial message sending routine to proceed further.
- Timeout Handler: When a response
message is not received and a timeout takes
place, the serial message sending routine calls this handler. Depending on requirement,
one of the following options may be chosen:
- Timeout handler retries by resending the command message to the entity that timed out.
- The timed out entity is skipped and serial message sending routine is informed to proceed further.
- As soon as a timeout takes place, serial message sending routine reports an unsuccessful completion of serial operation.
Participants
The key participants in this pattern are the task sending the message to multiple entities serially and the tasks on these entities that receive this command message, perform the desired operation and send back the response message.
Collaboration
The state machine implementing the Serial Wait state pattern collaborates with the tasks on the entities where some desired operation needs to be performed. The state machine keeps a timer to keep track of each operation being performed at each entity.
Consequences
Serial state pattern can result in triggering a state transition corresponding to successful collection of response messages. If a timeout takes place before the collection of response messages has been completed, a state transition to an error handling state might be initiated.
Implementation
Implementing the Serial Wait State Pattern involves sending request messages to one entity at a time and waiting for the response before moving on to the next entity. The implementation sequence is illustrated by the following example based on digital trunk status response to an operator command.
A digital trunk controller initiates diagnostics in series if there is a concern with peak power consumption due to diagnostics running in parallel .
- Serial Wait State is runs the diagnostics on the first digital trunk by sending a command.
- A timer is initiated to wait for the diagnostics response.
- On receipt of the response from the first digital trunk controller, the Serial Wait State proceeds by sending the diagnostics request command message to the next digital trunk controller.
- When the last digital trunk controller responds, the aggregate response can be sent back to the operator.
Sample Code and Usage
Here is the sample code for the digital trunk status check example:
Digital Trunk Status Check Using the Serial Wait State Pattern
Known Uses
This design pattern has been used in the following cases:
- Serial initialization of multiple modules during system initialization.
- Polling of multiple entities in sequence.
- Responding to an operator command requesting information about multiple entities.
Related Patterns
- Feature Coordination Design Pattern like serial coordination is an example of a general mechanism of handling a similar operation on multiple entities.
- Collector State Pattern
- Parallel Wait State Pattern