Path: utzoo!utgpu!water!watmath!clyde!att!lzaz!hutch
From: hutch@lzaz.ATT.COM (R.HUTCHISON)
Newsgroups: comp.unix.wizards
Subject: Re: P/V using SysV semop(2)
Message-ID: <217@lzaz.ATT.COM>
Date: 29 Aug 88 15:08:23 GMT
References: <2200029@hpisoa1.HP.COM>
Organization: AT&T ISL Lincroft NJ USA
Lines: 30

From article <2200029@hpisoa1.HP.COM>, by vandys@hpisoa1.HP.COM (Andrew Valencia):
] / 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.
] 
...
] 					Andy

Ah, but all processes sleeping awaiting a semaphore "unblock" sleep with the
same priority (PSEMN)- the CPU consumption factor (p_cpu) is not taken into
consideration when assigning priorities to sleeping processes.  Processes
are removed from the run queue using the following rules:

1) select the process with the highest priority
2) if there is a tie, select the one nearest the end of the queue

All processes sleeping on a semaphore sleep at priority PSEMN.  WHen
they are put on the run queue, they will have the same priority.  In
this case, their ordering is important.


Bob Hutchison
att!lzaz!hutch