Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Advanced topics
specify both blocking states for the flags argument to TimerTimeout(), because the
client might get blocked in either state.
To specify multiple states, you simply OR them together:
TimerTimeout (... _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY, ...);
This causes the timeout to be active whenever the kernel enters either the
SEND-blocked state or the REPLY-blocked state. There’s nothing special about
entering the SEND-blocked state and timing out — the server hasn’t received the
message yet, so the server isn’t actively doing anything on behalf of the client. This
means that if the kernel times out a SEND-blocked client, the server doesn’t have to be
informed. The client’s MsgSend() function returns an ETIMEDOUT indication, and
processing has completed for the timeout.
However, as was mentioned in the Message Passing chapter (under
“_NTO_CHF_UNBLOCK”), if the server has already received the client’s message, and
the client wishes to unblock, there are two choices for the server. If the server has not
specified _NTO_CHF_UNBLOCK on the channel it received the message on, then the
client will be unblocked immediately, and the server won’t receive any indication that
an unblock has occurred. Most of the servers I’ve seen always have the
_NTO_CHF_UNBLOCK flag enabled. In that case, the kernel delivers a pulse to the
server, but the client remains blocked until the server replies! As mentioned in the
above-referenced section of the Message Passing chapter, this is done so that the server
has an indication that it should do something about the client’s unblock request.
Summary
We’ve looked at Neutrino’s time-based functions, including timers and how they can
be used, as well as kernel timeouts. Relative timers provide some form of event “in a
certain number of seconds,” while absolute timers provide this event “at a certain
time.” Timers (and, generally speaking, the struct sigevent) can cause the
delivery of a pulse, a signal, or a thread to start.
The kernel implements timers by storing the absolute time that represents the next
“event” on a sorted queue, and comparing the current time (as derived by the timer tick
interrupt service routine) against the head of the sorted queue. When the current time
is greater than or equal to the first member of the queue, the queue is processed (for all
matching entries) and the kernel dispatches events or threads (depending on the type
of queue entry) and (possibly) reschedules.
To provide support for power-saving features, you should disable periodic timers when
they’re not needed — otherwise, the power-saving feature won’t implement power
saving, because it believes that there’s something to “do” periodically.
You could also use the CLOCK_SOFTTIME clock source, unless of course you
actually wanted the timer to defeat the power saving feature.
Given the different types of clock sources, you have flexibility in determining the basis
of your clocks and timer; from “real, elapsed” time through to time sources that are
based on power management activities.
April 30, 2009 Chapter 3 • Clocks, Timers, and Getting a Kick Every So Often 165