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" usage field 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 every process 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 //nice00 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 //nice00 to other processes ,which may include your own-. $n general, multilevel feedback 3ueue schedulers are comple. pieces of software that must be tuned to meet re3uirements. 4nomalies and system effects associated with schedulers. Priority interacts with synchroni5ation to create a really nasty effect called priority inversion. 4 priority inversion happens when a low6priority thread ac3uires a lock, then a high6priority thread tries to ac3uire the lock and blocks. 4ny middle6priority threads will prevent the low6 priority thread from running and unlocking the lock. $n effect, the middle6priority threads block the high6priority thread. 7ow to prevent priority inversions8 "se priority inheritance. 4ny time a thread holds a lock that other threads are waiting on, give the thread the priority of the highest6priority thread waiting to get the lock. Problem is that priority inheritance makes the scheduling algorithm less efficient and increases the overhead. Preemption can interact with synchroni5ation in a multiprocessor conte.t to create another nasty effect 6 the convoy effect. +ne thread ac3uires the lock, then suspends. +ther threads come along, 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 synchroni5ed, and will convoy their way through the lock, seriali5ing the computation. *o, drives down the processor utili5ation. $f have non6blocking synchroni5ation via operations like 99'*!, don0t get convoy effects caused by suspending a thread competing for access to a resource. :hy not8 #ecause threads don0t 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 e.ecute their bursts 3uickly and 3ueue up for access to the $+ device. The !P" bound process then e.ecutes for a long time. <uring this time all of the $+ bound processes have their $+ re3uests satisfied and move back into the run 3ueue. #ut they don0t run 6 the !P" bound process is running instead 6 so the $+ device idles. ;inally, the !P" bound process gets off the !P", and all of the $+

bound processes run for a short time then 3ueue up again for the $+ devices. =esult is poor utili5ation of $+ device 6 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 easy solution 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 utili5ation of the other resources in the system.