In a way, but perhaps its more accurate to think of priority as a last resort scheduling mechanism. A computer system has one or more processors each of which has only one program counter (the register that holds the address of the next instruction to be executed). Execution (=occupation of the program counter) will continue for a time slice, at which point another process is allowed in. But these days processes are likely to be waiting on I/O far more often than they are occupying memory, in which case they let other processes have their turn at a slice and are unlikely to block another process even for one turn. So in practice, it is extremely unlikely that a process will hog the CPU, unless either it is erroneously looping, which should not in any case be solved by adjusting priorities, or unless the system is truly saturated with many demanding processes, in which case only a system administrator can affect things with a negative (realtime) priority and of course he shouldn't do so, because slowing a host of processes for the sake of just one is unlikely to be desirable.Thus, what I am saying is that from a development/support perspective, process priority should also be about the last place to look for the problem.
| [reply] |