Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ucbvax!hplabs!hpda!hpcupt1!hpisoa1!vandys
From: vandys@hpisoa1.HP.COM (Andrew Valencia)
Newsgroups: comp.unix.wizards
Subject: Re: P/V using SysV semop(2)
Message-ID: <2200029@hpisoa1.HP.COM>
Date: 26 Aug 88 20:42:41 GMT
References: <1001@uwbull.uwbln.UUCP>
Organization: Hewlett Packard, Cupertino
Lines: 19

/ hpisoa1:comp.unix.wizards / hutch@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