Getting Started with QNX Neutrino - QNX Software Systems

The kernel’s role
© 2009, QNX Software Systems GmbH & Co. KG.
The CPU has a number of registers (the exact number depends on the processor
family, e.g., x86 versus MIPS, and the specific family member, e.g., 80486 versus
Pentium). When the thread is running, information is stored in those registers (e.g., the
current program location).
When the kernel decides that another thread should run, it needs to:
1 save the currently running thread’s registers and other context information
2 load the new thread’s registers and context into the CPU
But how does the kernel decide that another thread should run? It looks at whether or
not a particular thread is capable of using the CPU at this point. When we talked about
mutexes, for example, we introduced a blocking state (this occurred when one thread
owned the mutex, and another thread wanted to acquire it as well; the second thread
would be blocked).
From the kernel’s perspective, therefore, we have one thread that can consume CPU,
and one that can’t, because it’s blocked, waiting for a mutex. In this case, the kernel
lets the thread that can run consume CPU, and puts the other thread into an internal list
(so that the kernel can track its request for the mutex).
Obviously, that’s not a very interesting situation. Suppose that a number of threads can
use the CPU. Remember that we delegated access to the mutex based on priority and
length of wait? The kernel uses a similar scheme to determine which thread is going to
run next. There are two factors: priority and scheduling algorithm, evaluated in that
order.
Prioritization
Consider two threads capable of using the CPU. If these threads have different
priorities, then the answer is really quite simple — the kernel gives the CPU to the
highest priority thread. Neutrino’s priorities go from one (the lowest usable) and up, as
we mentioned when we talked about obtaining mutexes. Note that priority zero is
reserved for the idle thread — you can’t use it. (If you want to know the minimum and
maximum values for your system, use the functions sched_get_priority_min() and
sched_get_priority_max() — they’re prototyped in . In this book, we’ll
assume one as the lowest usable, and 255 as the highest.)
If another thread with a higher priority suddenly becomes able to use the CPU, the
kernel will immediately context-switch to the higher priority thread. We call this
preemption — the higher-priority thread preempted the lower-priority thread. When
the higher-priority thread is done, and the kernel context-switches back to the
lower-priority thread that was running before, we call this resumption — the kernel
resumes running the previous thread.
Now, suppose that two threads are capable of using the CPU and have the exact same
priority.
20 Chapter 1 • Processes and Threads April 30, 2009