[H-GEN] Priorities

Greg Black gjb at gbch.net
Fri Jun 6 22:32:29 EDT 2003


On 2003-06-06, Robert Brockway wrote:
> On Fri, 6 Jun 2003, Greg Black wrote:
> > The algorithm varies also, but the general feature is that the
> 
> Definately, and with some interesting side effects.  Under some unices a
> process with a nice value 20 (or whatever maximum nice value happens to
> be) is not guaranteed any time on the cpu.  This can lead to an effect
> known as "process starvation" where a nice 20 process sits idle forever
> because something always has a higher priority and so gets the cpu ahead
> of it.  Many unices these days force at least a little time to any process
> - even something at nice 20.

I'd have to study the source a bit to be sure what happens
there, but I suspect that most priority algorithms work in such
a way that all processes will get a shot at the CPU eventually.

However, if a user or a program sets it nice value as high as
possible and then doesn't get much CPU time, we know who to
blame :-)

> Although the idea of starving a process can initially seem attractive (eg,
> guaranteeing that seti at home only runs when absolutely nothing else is
> occuring) I can see why we would want any process to have at least some
> time on the cpu.  Unexpected external events involving the process can
> occur (eg, the process may receive a signal), and the process may need
> time on the cpu to deal with that.  If a process was starved then it would
> never get to deal with the signal, which would be stuck in a kernel data
> structure until the end of time :)

This would not happen.  When a signal is posted for a process, a
large set of things gets done in the kernel -- e.g., checks to
see if the signal is being ignored or masked; checks to see if
the process is blocked on an event or stopped by a signal;
etc. -- but eventually it determines whether or not the signal
is to be delivered.  If the signal is to be delivered, and the
process is runnable but not the current process, it is marked as
needing to be scheduled, so it will effectively get a very high
priority and be set to run in order for the signal to be able to
be delivered/noticed[1].

Greg

[1] This is true for BSD; I'd be surprised if it was not true
    for other systems, although I haven't bothered to check.

-- 
Greg Black <gjb at gbch.net> <http://www.gbch.net/gjb.html>
GPG signed mail preferred; further information in headers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20030607/0be191f4/attachment.sig>


More information about the General mailing list