8/12/2019 process priority in unix

1/2

Processes are given a base priority of 60, with lower numbers representing higher priorities.

The system clock generates an interrupt between 50 and 00 times a second, so we will assume a

value of 60 clock interrupts per second. The clock interrupt handler increments a !P" usagefield in the P!# of the interrupted process every time it runs.

The system always runs the highest priority process. $f there is a tie, it runs the process that

has been ready longest. %very second, it recalculates the priority and !P" usage field for everyprocess according to the following formulas.

!P" usage field & !P" usage field ' (

Priority & !P" usage field ' ( ) base priority

*o, when a process does not use much !P" recently, its priority rises. The priorities of $+

bound processes and interactive processes therefore tend to be high and the priorities of !P"bound processes tend to be low which is what you want-.

"ni also allows users to provide a //nice value for each process. 1ice values modify the

priority calculation as follows2

Priority & !P" usage field ' ( ) base priority ) nice value

*o, you can reduce the priority of your process to be //nice to other processes which may

include your own-.

$n general, multilevel feedback 3ueue schedulers are comple pieces of software that must betuned to meet re3uirements.

4nomalies and system effects associated with schedulers.

Priority interacts with synchroniation to create a really nasty effect called priority inversion.4 priority inversion happens when a lowpriority thread ac3uires a lock, then a highpriority

thread tries to ac3uire the lock and blocks. 4ny middlepriority threads will prevent the low

priority thread from running and unlocking the lock. $n effect, the middlepriority threads blockthe highpriority thread.

7ow to prevent priority inversions8 "se priority inheritance. 4ny time a thread holds a lockthat other threads are waiting on, give the thread the priority of the highestpriority threadwaiting to get the lock. Problem is that priority inheritance makes the scheduling algorithm less

efficient and increases the overhead.

Preemption can interact with synchroniation in a multiprocessor contet to create another

nasty effect the convoy effect. +ne thread ac3uires the lock, then suspends. +ther threads comealong, and need to ac3uire the lock to perform their operations. %verybody suspends until the

lock that has the thread wakes up. 4t this point the threads are synchronied, and will convoy

their way through the lock, serialiing the computation. *o, drives down the processorutiliation.

$f have nonblocking synchroniation via operations like 99'*!, dont get convoy effects

caused by suspending a thread competing for access to a resource. :hy not8 #ecause threadsdont hold resources and prevent other threads from accessing them.

*imilar effect when scheduling !P" and $+ bound processes. !onsider a ;!;* algorithm

with several $+ bound and one !P" bound process. 4ll of the $+ bound processes eecute their

bursts 3uickly and 3ueue up for access to the $+ device. The !P" bound process then eecutesfor a long time.

8/12/2019 process priority in unix

2/2

bound processes run for a short time then 3ueue up again for the $+ devices. =esult is poor

utiliation of $+ device it is busy for a time while it processes the $+ re3uests, then idle while

the $+ bound processes wait in the run 3ueues for their short !P" bursts. $n this case an easysolution is to give $+ bound processes priority over !P" bound processes.

$n general, a convoy effect happens when a set of processes need to use a resource for a short

time, and one process holds the resource for a long time, blocking all of the other processes.!auses poor utiliation of the other resources in the system.