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.

Serial Message Interactions

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

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:

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 .

  1. Serial Wait State is runs the diagnostics on the first digital trunk by sending a command.
  2. A timer is initiated to wait for the diagnostics response.
  3. 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.
  4. 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:

Related Patterns