Every process has an absolute priority, and it is represented by a number. The higher the number, the higher the absolute priority.
On systems of the past, and most systems today, all processes have absolute priority 0 and this section is irrelevant. In that case, See Traditional Scheduling. Absolute priorities were invented to accommodate realtime systems, in which it is vital that certain processes be able to respond to external events happening in real time, which means they cannot wait around while some other process that wants to, but doesn’t need to run occupies the CPU.
When two processes are in contention to use the CPU at any instant, the one with the higher absolute priority always gets it. This is true even if the process with the lower priority is already using the CPU (i.e., the scheduling is preemptive). Of course, we’re only talking about processes that are running or “ready to run,” which means they are ready to execute instructions right now. When a process blocks to wait for something like I/O, its absolute priority is irrelevant.
NB: The term “runnable” is a synonym for “ready to run.”
When two processes are running or ready to run and both have the same absolute priority, it’s more interesting. In that case, who gets the CPU is determined by the scheduling policy. If the processes have absolute priority 0, the traditional scheduling policy described in Traditional Scheduling applies. Otherwise, the policies described in Realtime Scheduling apply.
You normally give an absolute priority above 0 only to a process that can be trusted not to hog the CPU. Such processes are designed to block (or terminate) after relatively short CPU runs.
A process begins life with the same absolute priority as its parent process. Functions described in Basic Scheduling Functions can change it.
Only a privileged process can change a process’ absolute priority to
something other than 0. Only a privileged process or the
target process’ owner can change its absolute priority at all.
POSIX requires absolute priority values used with the realtime
scheduling policies to be consecutive with a range of at least 32. On
Linux, they are 1 through 99. The functions
sched_get_priority_max and sched_set_priority_min portably
tell you what the range is on a particular system.
One thing you must keep in mind when designing real time applications is that having higher absolute priority than any other process doesn’t guarantee the process can run continuously. Two things that can wreck a good CPU run are interrupts and page faults.
Interrupt handlers live in that limbo between processes. The CPU is executing instructions, but they aren’t part of any process. An interrupt will stop even the highest priority process. So you must allow for slight delays and make sure that no device in the system has an interrupt handler that could cause too long a delay between instructions for your process.
Similarly, a page fault causes what looks like a straightforward
sequence of instructions to take a long time. The fact that other
processes get to run while the page faults in is of no consequence,
because as soon as the I/O is complete, the higher priority process will
kick them out and run again, but the wait for the I/O itself could be a
problem. To neutralize this threat, use mlock or
mlockall.
There are a few ramifications of the absoluteness of this priority on a single-CPU system that you need to keep in mind when you choose to set a priority and also when you’re working on a program that runs with high absolute priority. Consider a process that has higher absolute priority than any other process in the system and due to a bug in its program, it gets into an infinite loop. It will never cede the CPU. You can’t run a command to kill it because your command would need to get the CPU in order to run. The errant program is in complete control. It controls the vertical, it controls the horizontal.
There are two ways to avoid this: 1) keep a shell running somewhere with a higher absolute priority or 2) keep a controlling terminal attached to the high priority process group. All the priority in the world won’t stop an interrupt handler from running and delivering a signal to the process if you hit Control-C.
Some systems use absolute priority as a means of allocating a fixed percentage of CPU time to a process. To do this, a super high priority privileged process constantly monitors the process’ CPU usage and raises its absolute priority when the process isn’t getting its entitled share and lowers it when the process is exceeding it.
NB: The absolute priority is sometimes called the “static priority.” We don’t use that term in this manual because it misses the most important feature of the absolute priority: its absoluteness.