Timer Management Patterns

In this article we shall be covering different timer management design patterns used in Real-time and Embedded system design.

The following timer management design patterns are used very frequently in Real-time systems:

Recovering from Message Loss

Usually a timer is kept while awaiting for a message. If the message is received, timer is stopped. If the timer expires, message loss is registered. In such a case, a retry logic is implemented by restarting the timer and awaiting for the message again. If the number of retries reaches a threshold, the activity is aborted and appropriate recovery action is initiated.

Recovering from Software Faults

Whenever a feature is initiated, a feature wide timer is kept to ensure feature success. If some software or hardware module involved in the feature hits recovery, the feature will fail and the timer expiry will be the only method to detect the feature failure. On expiry of the feature wide timer, the feature may be re-initiated or recovery action might be taken.

It is a good design practice to keep at least one timer active during the execution of a feature. The timer guards the system against unforeseen failure conditions.

Sequencing Operations

Timers are used for sequencing time based state transitions. Consider the traffic light controller where after each light operation, the controller has to wait for some defined amount of time. For example, timers can manage the transition between green, yellow and red. When a timer expires, the traffic light is moved to its next logical condition and a timer is started for the next transition. 

Polling

In most systems, events are reported via messages. But sometimes it may not be practical to report the occurrence of an event via a message. So a timer is kept and the system polls for that condition on every timeout.

Consider the implementation of a congestion control system. The software runs a periodic congestion polling timer that polls for the CPU utilization and other congestion triggers. When the CPU utilizations reaches a threshold, the congestion control action is taken.

Periodic Operations

For implementing audits, periodic timers are kept. On each timer expiry, software audit is initiated. Another example where periodic timers are used could be implementing periodic billing of calls in telecom systems. When the call enters conversation, the periodic timer is started. On every timeout, the subscriber meter is incremented.

Failure Detection

For monitoring the health of other modules, a module runs a timer. It expects a sanity punch message periodically from all the other modules before the expiry of the timer. If certain number of sanity punches are missed in succession from a module, module failure is declared as failed.

Collecting Messages

Many times timers are used to collect messages. For example, in the digit collection procedure for a call, the system restarts a timer each time a digit message is received. The end of dialing is either received in the message or the timer expiry indicates it. No timer is started after the end of dialing is detected. Partial dialing is reported if the end of dialing is detected before the receipt of minimum number of digits required to route the call

Inactivity Detection

Timers are also used for detecting the inactivity in a session. Consider the case of a user session on the internet. Each time there is any kind of action by the user, the inactivity timer is restarted by the ISP. If the timer expires, the ISP terminates the user session and the internet connection is lost.