P/V using SysV semop(2)

Andrew Valencia vandys at hpisoa1.HP.COM
Sat Aug 27 06:42:41 AEST 1988


/ hpisoa1:comp.unix.wizards / hutch at lzaz.ATT.COM (R.HUTCHISON) /  5:45 am  Aug 25, 1988 /
>The order is predictable - it is Last-In-First-Out.  This is because
>processes waiting for semaphores move back and forth between the run
>queue and sleep queues each time there is a possibility that a process
>can be awakened.

    I don't know about your implementation, but on ours user processes change
priority as they consume (and over-consume :->) CPU and then fall idle.  So
when a batch of processes move from the sleep queue to the run queue, there's
no simple way (from a user's perspective) to say who's going to run.

    An area to be careful in is real-time scheduling (if your kernel has
it).  Our system design philosophy says that real-time priority processes
*should* be able to starve lower priority processes when competing for these
semaphores.  A simple FIFO queue for the semaphore would violate this;
multiple queues (one for each priority level) is a bit much.  Using priorities
and FIFO sleep & run queues makes it work out pretty well.

					Andy



More information about the Comp.unix.wizards mailing list