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