increasing order. New events are inserted in order and can be expensive if the overflow buffer contains a large number of entries.
Another issue associated with the timing wheel approach is the precision of the installed timeouts. Consider the situation in which a 150ms timer event is being scheduled while the clock is ticking but before the tick announcement reaches the timing wheel. Should the timer event be added to the +150ms slot or placed in the +200ms slot? On average, the error is approximately half the size of the tick. In this example, the error is about 25ms.
One other important issue relates to the invocation time of the callbacks installed at each time slot. In theory, the callbacks should all be invoked at the same time at expiration, but in reality, this is impossible. The work performed by each callback is unknown; therefore, the execution length of each callback is unknown. Consequently, no guarantee or predictable measures exist concerning when a callback in a later position of the list can be called, even in a worst-case scenario. This issue introduces non-determinism into the system and is undesirable. Figure 11.15 illustrates the problem.
Figure 11.15: Unbounded soft-timer handler invocation.
Event handler 1 is invoked at
Ideally, the timer facility could guarantee an upper bound; for example, regardless of the number of timers already installed in the system, event handler
This problem is difficult, and the solution is application specific.
11.6.2 Hierarchical Timing Wheels
The timer overflow problem presented in the last section can be solved using the
The soft-timer facility needs to accommodate timer events spanning a range of values. This range can be very large. For example accommodating timers ranging from 100ms to 5 minutes requires a timing wheel with 3,000 (5 ? 60 ? 10) entries. Because the timer facility needs to have a granularity of at least 100ms and there is a single array representing the timing wheel,
10 ? 100ms = 1 sec
10 entries/sec
60 sec = 1 minute
60 ? 10 entries / min
therefore:
5 ? 60 ? 10 = total number of entries needed for the timing wheel with a granularity of 100ms.
A hierarchical timing wheel is similar to a digital clock. Instead of having a single timing wheel, multiple timing wheels are organized in a hierarchical order. Each timing wheel in the hierarchy set has a different granularity. A clock dial is associated with each timing wheel. The clock dial turns by one unit when the clock dial at the lower level of the hierarchy wraps around. Using a hierarchical timing wheel requires only 75 (10 + 60 + 5) entries to allow for timeouts with 100ms resolution and duration of up to 5 minutes.
With a hierarchical timing wheels, there are multiple arrays, therefore
10 ? 100ms = 1 sec
10 entries/sec
the 1st array (leftmost array as shown in Figure 11.16)
Figure 11.16: A hierarchical timing wheel.
60 sec = 1 minute
60 entries / min
the 2nd array (middle array shown in Figure 11.16)
5 entries for 5 minutes
3rd array
therefore:
5 + 60 + 10 = total number of entries needed for the hierarchal timing wheels.
The reduction in space allows for the construction of higher precision timer facilities with a large range of timeout values. Figure 11.16 depicts this concept.
For example, it is possible to install timeouts of 2 minutes, 4 seconds, and 300 milliseconds. The timeout handler is installed at the 2-minute slot first. The timeout handler determines that there are still 4.3 seconds to go when the 2 minutes is up. The handler installs itself at the 4-second timeout slot. Again, when 4 seconds have elapsed, the same handler determines that 300 milliseconds are left before expiring the timer. Finally, the handler is reinstalled at the 300-millisecond timeout slot. The real required work is performed by the handler when the last 300ms expire.
11.7 Soft Timers and Timer Related Operations
Many RTOSs provide a set of timer-related operations for external software components and applications through API sets. These common operations can be cataloged into these groups:
· group 1 - provides low-level hardware related operations,
· group 2 - provides soft-timer-related services, and
· group 3 - provides access either to the storage of the real-time clock or to the system clock.
Not all of the operations in each of these three groups, however, are offered by all RTOSs, and some RTOSs provides additional operations not mentioned here.
The first group of operations is developed and provided by the BSP developers. The group is considered low-level system operations. Each operation in the group is given a fictitious function name for this discussion. Actual function names are implementation dependent.
Table 11.1: Group 1 Operations.
Typical Operations | Description |
---|---|
sys_timer_enable | Enables the system timer chip interrupts. As soon as this operation is invoked, the timer interrupts occur at the preprogrammed frequency, assuming that the timer chip has been properly initialized with the desired values. Only after this operation is complete can kernel task scheduling take place. |