Parallel Wait State Design Pattern

Parallel Wait State Pattern

Real-time software sometimes involves handling parallel interactions withmultiple entities to initiate some action. Further action can be initiated onlyafter response message has been received from all the entities. Parallel Waitstate pattern handles such scenarios.

The figure below shows a typical parallel operation. Here A initiates aparallel operation by sending a request to B, C and D. B, C and D perform theoperation in parallel and respond back to A.

Intent

The main intention here is to initiate similar activity on multiple entitiesin parallel. Since activities are initiated in parallel, the time taken toperform the task is more or less independent of the number of entities involvedin the interaction. This is faster in comparison to Serial Wait State patternwhere one message is sent to initiate an activity on an entity, its response isawaited and only on receipt of the response same activity is initiated on thenext entity.

The main objective of this design pattern is to efficiently handle scenarioswhere sending of similar message to multiple entities to initiate similaractivity in parallel is involved. Here, a response is expected from each entityafter the entity finishes the activity. This also involves counting the receivedresponse messages and recognizing the point where collection has been completed.

Also Known As

Simultaneous Action State Pattern

Parallel Interaction

Motivation

Main motivation to use Parallel Wait State is to speed up operations withmultiple entities. If a particular operation takes a long time to perform,initiating the operation in parallel will be the most time efficient way ofperforming that operation. Such designs scale very well with increase in numberof entities handled by the system.

Applicability

The Parallel Wait State pattern can be used wherever multiple operations needto be initiated on multiple entities. This pattern can be applied when paralleloperation does not cause an undue loading of the systems. This design patternshould not be used in scenarios where each operation is extremely resourceintensive and parallel operation might consume too many system resources at thesame time.

Structure

This pattern consists of the following event handlers:

Parallel Message Sending Routine: This routine sends message to multiple entities in one shot. This routine also starts a timer to keep track of parallel response collection.

Parallel Response Handler: This handler receives the response messages being collected and takes a decision when collection has been completed. The collection is assumed to have been completed, when the parallel response count matches the number of requests sent to multiple entities.

Timeout Handler: When a timeout takes place, the parallel message sending routine calls this handler. If the parallel response count is less than the number of messages sent, timeout signals failure of response message collection. Otherwise, timeout signals a successful response message collection. Depending on requirement, the timeout handler retries by resending the command message to the entity that timed out and keeps a timer to await the response.

Participants

The key participants in this pattern are the task sending the message tomultiple entities and the tasks on these entities that receive this commandmessage, perform the desired operation and send back the response message.

Collaboration

The state machine implementing the parallel state pattern collaborates withthe tasks on the entities where some desired operation needs to be performed.The state machine keeps a timer to keep track of the operation being performedat each entity.

Consequences

Parallel state pattern can result in triggering a state transitioncorresponding to successful collection of response messages. If a timeout takes placebefore the collection of response messages has been completed, a state transition to an errorhandling state might be initiated.

Implementation

Implementing the Parallel Wait State Pattern involves sending requestmessages in parallel and waiting till all responses are collected. Theimplementation sequence is illustrated by the following example based on digitaltrunk diagnostics.

In theXenon switching system XEN Configuration Manager(XCM) needs to initiate diagnostics on all the digital trunk circuits controlledby the XEN. This is done by sending diagnostics request message to all the circuits andwaiting for response from each circuit. Once the responses are received from all thecircuits, XCM responds back to the initiator.

Parallel Wait State is invoked to start diagnostics on all the digital trunks in the XEN.

Parallel Wait State loops through the list of digital trunk circuits and sends a diagnostics request to each circuit. A timer is initiated to wait for diagnostics response. A counter is incremented to keep track of number of requests.

The diagnostics progress in parallel and the digital trunk cards respond back on completion of diagnostics.

The Parallel Wait State receives the responses from all the digital trunk. It decrements the counter when a response is successfully received.

When the counter goes down to zero, all responses have been received, so the aggregate response can be sent back.

Sample Code and Usage

Here is the sample code for the digital trunk diagnostics example:

Digital Trunk Diagnostics Using the Parallel Wait State Pattern

class CPerformingDiagnosticsState : public CState { int m_nOutstandingRequests; // Count of outstanding diagnostics requests public: // Send out the diagnostics requests void InitiateDiagnostics(CStateMachine &m) { DigitalTrunk *pTrunk; m_nOutstandingRequests = 0; for (int i=0; i < DIGITAL_TRUNK_COUNT; i++) { // Obtain a pointer to the digital trunk pTrunk = m.GetDigitalTrunk(i); // Send the diagnostics request to this trunk m.SendDiagnosticsRequest(pTrunk->GetTrunkId()); // Update Trunk State pTrunk->SetState(AWAITING_DIAGNOSTICS); // Keep track of outstanding requests m_nOutstandingRequests++; } // Starting a single timer to keep track of responses StartTimer(); } // Handle Diagnostics Response void OnDiagnositcsResponse(CStateMachine& m, const DiagnosticsResponse* pMsg) { DigitalTrunk *pTrunk = m.GetDigitalTrunk(pMsg->GetTrunkId()); // Check if the response has been received from a valid terminal in a valid state if (pTrunk->GetState() != AWAITING_DIAGNOSTICS) { // No response is awaited from this terminal, so ignore the response return; } // Save the diagnostics status m.m_diagnosticsStatus[pMsg->GetTrunkId()] = pMsg->GetDiagnosticsStatus(); ASSERT (m_nOutstandingCount > 0); // One less response is outstanding. if (--m_nOutstandingRequests == 0) { // All responses have been received so stop the timer StopTimer(); // Now respond back with the status of all diagnostics responses m.SendCollectedDiagnosticsResponse(m.m_diagnositsStatus); // Going back to Idle State m.ChangeState(pIdleState); } } // Handle Timeout virtual void OnTimeout(CStateMachine& m) { TRACE("Response Missed from %d Digital Trunks\n", m_nOutstandingRequests); // Respond back whatever responses were received. m.SendCollectedDiagnosticsResponse(m.m_diagnositsStatus); // Going back to Idle State m.ChangeState(pIdleState); } };

Known Uses

This design pattern has been used in the following cases:

Initiating diagnostics on multiple entities

Parallel initialization of multiple modules during system initialization.

Polling of multiple entities in parallel

Related Patterns

Feature Design Pattern like serial coordination is an example of other general mechanism of handling a similar operation on multiple entities.

Collector State Pattern

Serial Wait State Pattern