Home >
Real-time Mantra >
Design Patterns > Timer Management Design Patterns
Timer Management Design 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:
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.
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 reinitiated 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.
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.
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.
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.
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.
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
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.
| 