Getting Started with QNX Neutrino - QNX Software Systems

Clocks and timers
© 2009, QNX Software Systems GmbH & Co. KG.
In those days, since nothing else was running on the machine, this didn’t present much
of a problem, because no other process cared that you were hogging 100% of the CPU
in the sleep() function.
Even today, we sometimes hog 100% of the CPU to do timing functions. Notably, the
nanospin() function is used to obtain very fine-grained timing, but it does so at the
expense of burning CPU at its priority. Use with caution!
If you did have to perform some form of “multitasking,” it was usually done via an
interrupt routine that would hang off the hardware timer or be performed within the
“busy-wait” period, somewhat affecting the calibration of the timing. This usually
wasn’t a concern.
Luckily we’ve progressed far beyond that point. Recall from “Scheduling and the real
world,” in the Processes and Threads chapter, what causes the kernel to reschedule
threads:
• a hardware interrupt
• a kernel call
• a fault (exception)
In this chapter, we’re concerned with the first two items on the list: the hardware
interrupt and the kernel call.
When a thread calls sleep(), the C library contains code that eventually makes a kernel
call. This call tells the kernel, “Put this thread on hold for a fixed amount of time.” The
call removes the thread from the running queue and starts a timer.
Meanwhile, the kernel has been receiving regular hardware interrupts from the
computer’s clock hardware. Let’s say, for argument’s sake, that these hardware
interrupts occur at exactly 10-millisecond intervals.
Let’s restate: every time one of these interrupts is handled by the kernel’s clock
interrupt service routine (ISR), it means that 10 ms have gone by. The kernel keeps
track of the time of day by incrementing its time-of-day variable by an amount
corresponding to 10 ms every time the ISR runs.
So when the kernel implements a 15-second timer, all it’s really doing is:
1 Setting a variable to the current time plus 15 seconds.
2 In the clock ISR, comparing this variable against the time of day.
3 When the time of day is the same as (or greater than) the variable, putting the
thread back onto the READY queue.
When multiple timers are outstanding, as would be the case if several threads all
needed to be woken at different times, the kernel would simply queue the requests,
sorting them by time order — the nearest one would be at the head of the queue, and
so on. The variable that the ISR looks at is the one at the head of this queue.
138 Chapter 3 • Clocks, Timers, and Getting a Kick Every So Often April 30, 2009