Clock Software

5.5.2 Clock Software

All the clock hardware does is generate interrupts at known intervals. Every- thing else involving time must be done by the software, the clock driver. The exact duties of the clock driver vary among operating systems, but usually include most of the following:

1. Maintaining the time of day.

2. Preventing processes from running longer than they are allowed to.

3. Accounting for CPU usage.

4. Handling the alar m system call made by user processes.

5. Providing watchdog timers for parts of the system itself.

6. Doing profiling, monitoring, and statistics gathering. The first clock function, maintaining the time of day (also called the real time)

is not difficult. It just requires incrementing a counter at each clock tick, as men- tioned before. The only thing to watch out for is the number of bits in the time-of- day counter. With a clock rate of 60 Hz, a 32-bit counter will overflow in just over

2 years. Clearly the system cannot store the real time as the number of ticks since Jan. 1, 1970 in 32 bits. Three approaches can be taken to solve this problem. The first way is to use a 64-bit counter, although doing so makes maintaining the counter more expensive since it has to be done many times a second. The second way is to maintain the time of day in seconds, rather than in ticks, using a subsidiary counter to count

ticks until a whole second has been accumulated. Because 2 32 seconds is more than 136 years, this method will work until the twenty-second century. The third approach is to count in ticks, but to do that relative to the time the system was booted, rather than relative to a fixed external moment. When the back- up clock is read or the user types in the real time, the system boot time is calcu- lated from the current time-of-day value and stored in memory in any convenient form. Later, when the time of day is requested, the stored time of day is added to the counter to get the current time of day. All three approaches are shown in Fig. 5-29.

The second clock function is preventing processes from running too long. Whenever a process is started, the scheduler initializes a counter to the value of that process’ quantum in clock ticks. At every clock interrupt, the clock driver decrements the quantum counter by 1. When it gets to zero, the clock driver calls the scheduler to set up another process.

The third clock function is doing CPU accounting. The most accurate way to do it is to start a second timer, distinct from the main system timer, whenever a process is started up. When that process is stopped, the timer can be read out to tell

SEC. 5.5

CLOCKS

32 bits Time of day in ticks

64 bits

32 bits

Counter in ticks

Time of day

Number of ticks

in seconds

in current second System boot time

in seconds (a)

(b)

(c)

Figure 5-29. Three ways to maintain the time of day.

how long the process has run. To do things right, the second timer should be saved when an interrupt occurs and restored afterward.

A less accurate, but simpler, way to do accounting is to maintain a pointer to the process table entry for the currently running process in a global variable. At ev ery clock tick, a field in the current process’ entry is incremented. In this way, ev ery clock tick is ‘‘charged’’ to the process running at the time of the tick. A minor problem with this strategy is that if many interrupts occur during a process’ run, it is still charged for a full tick, even though it did not get much work done. Properly accounting for the CPU during interrupts is too expensive and is rarely done.

In many systems, a process can request that the operating system give it a warning after a certain interval. The warning is usually a signal, interrupt, message, or something similar. One application requiring such warnings is networking, in which a packet not acknowledged within a certain time interval must be retrans- mitted. Another application is computer-aided instruction, where a student not pro- viding a response within a certain time is told the answer.

If the clock driver had enough clocks, it could set a separate clock for each re- quest. This not being the case, it must simulate multiple virtual clocks with a single physical clock. One way is to maintain a table in which the signal time for all pending timers is kept, as well as a variable giving the time of the next one. When- ev er the time of day is updated, the driver checks to see if the closest signal has oc- curred. If it has, the table is searched for the next one to occur.

If many signals are expected, it is more efficient to simulate multiple clocks by chaining all the pending clock requests together, sorted on time, in a linked list, as shown in Fig. 5-30. Each entry on the list tells how many clock ticks following the previous one to wait before causing a signal. In this example, signals are pending for 4203, 4207, 4213, 4215, and 4216.

In Fig. 5-30, the next interrupt occurs in 3 ticks. On each tick, Next signal is decremented. When it gets to 0, the signal corresponding to the first item on the list is caused, and that item is removed from the list. Then Next signal is set to the value in the entry now at the head of the list, in this example, 4.

INPUT/OUTPUT CHAP. 5

Current time

Next signal

Figure 5-30. Simulating multiple timers with a single clock.

Note that during a clock interrupt, the clock driver has several things to do— increment the real time, decrement the quantum and check for 0, do CPU ac- counting, and decrement the alarm counter. Howev er, each of these operations has been carefully arranged to be very fast because they hav e to be repeated many times a second.

Parts of the operating system also need to set timers. These are called watch- dog timers and are frequently used (especially in embedded devices) to detect problems such as hangs. For instance, a watchdog timer may reset a system that stops running. While the system is running, it regularly resets the timer, so that it never expires. In that case, expiration of the timer proves that the system has not run for a long time, and leads to corrective action—such as a full-system reset.

The mechanism used by the clock driver to handle watchdog timers is the same as for user signals. The only difference is that when a timer goes off, instead of causing a signal, the clock driver calls a procedure supplied by the caller. The pro- cedure is part of the caller’s code. The called procedure can do whatever is neces- sary, even causing an interrupt, although within the kernel interrupts are often inconvenient and signals do not exist. That is why the watchdog mechanism is pro- vided. It is worth nothing that the watchdog mechanism works only when the clock driver and the procedure to be called are in the same address space.

The last thing in our list is profiling. Some operating systems provide a mech- anism by which a user program can have the system build up a histogram of its program counter, so it can see where it is spending its time. When profiling is a possibility, at every tick the driver checks to see if the current process is being pro- filed, and if so, computes the bin number (a range of addresses) corresponding to the current program counter. It then increments that bin by one. This mechanism can also be used to profile the system itself.