We've seen the clock source CLOCK_REALTIME, and mentioned that a POSIX conforming implementation may supply as many different clock sources as it feels like, provided that it at least provides CLOCK_REALTIME.
What is a clock source? Simply put, it's an abstract source of timing information. If you want to put it into real life concepts, your personal watch is a clock source; it measures how fast time goes by. Your watch will have a different level of accuracy than someone else's watch. You may forget to wind your watch, or get it new batteries, and time may seem to “freeze” for a while. Or, you may adjust your watch, and all of a sudden time seems to “jump.” These are all characteristics of a clock source.
(QNX Neutrino provides some special clock sources that you can use to track how much CPU time a process or thread uses, but they're beyond the scope of this chapter. See “Monitoring execution times” in the “Understanding the Microkernel's Concept of Time” chapter of the QNX Neutrino Programmer's Guide.)
Under QNX Neutrino, CLOCK_REALTIME is based off of the “current time of day” clock that the OS provides. (In the examples below, we refer to this as “QNX Neutrino time.”) This means that if the system is running, and suddenly someone adjusts the time forward by 5 seconds, the change may or may not adversely affect your programs (depending on what you're doing). Let's look at a sleep (30); call:
| Real time | QNX Neutrino time | Activity |
|---|---|---|
| 11:22:05 | 11:22:00 | sleep (30); |
| 11:22:15 | 11:22:15 | Clock gets adjusted to 11:22:15; it was 5 seconds too slow! |
| 11:22:35 | 11:22:35 | sleep (30); wakes up |
Beautiful! The thread did exactly what you expected: at 11:22:00 it went to sleep for thirty seconds, and at 11:22:35 (thirty elapsed seconds later) it woke up. Notice how the sleep() “appeared” to sleep for 35 seconds, instead of 30; in real, elapsed time, though, only 30 seconds went by because QNX Neutrino's clock got adjusted ahead by five seconds (at 11:22:15).
The kernel knows that the sleep() call is a relative timer, so it takes care to ensure that the specified amount of “real time” elapses.
Now, what if, on the other hand, we had used an absolute timer, and at 11:22:00 in “QNX Neutrino time” told the kernel to wake us up at 11:22:30?
| Real time | QNX Neutrino time | Activity |
|---|---|---|
| 11:22:05 | 11:22:00 | Wake up at 11:22:30 |
| 11:22:15 | 11:22:15 | Clock gets adjusted as before |
| 11:22:30 | 11:22:30 | Wakes up |
This too is just like what you'd expect—you wanted to be woken up at 11:22:30, and (in spite of adjusting the time) you were. However, in real time, the timer expired after 25 seconds, instead of the full 30. Depending on the application, this could be a problem.