serge@imag.imag.fr (Serge Rouveyrol) (04/24/89)
On Xinu when more than one process are waiting on a semaphore, and when an other process execute a signal on this semaphore, it is not the process with the biggest priority who is wake up. This , is a problem for a real-time application. N'est ce pas ? -- "Les jours de pluie ... etc ... " serge@imag.imag.fr serge@imag.UUCP uunet.uu.net!imag!serge Rouveyrol Serge,Laboratoire L.G.I,BP 53,38041 Grenoble , CEDEX , FRANCE
comer@CS.PURDUE.EDU (Douglas Comer) (04/25/89)
>> On Xinu when more than one process are waiting on a semaphore, >> and when an other process execute a signal on this semaphore, >> it is not the process with the biggest priority who is wake up. >> This , is a problem for a real-time application. >> >> N'est ce pas ? Well...there are a couple of ways to look at "priority". Xinu defines the process priority to mean only scheduling priority, and separates the semaphore queuing policy from the process scheduling policy. Such separation of policy makes understanding computations simpler because one doesn't have to know the effect of scheduling priority on use of other resources (e.g., on I/O). If you desire a different scheduling policy for semaphores, it's easy to change Xinu because the policy is contained only in a few routines. However, before doing so, you should also consider adding a special set of routines for coordination using your policy and leaving the general-purpose semaphore system alone. okeydokey? Doug