Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!modcomp!joe
From: joe@modcomp.UUCP
Newsgroups: comp.arch
Subject: Re: Mips, Mach, test-and-set
Message-ID: <90800005@modcomp>
Date: 24 Oct 89 16:48:00 GMT
References: <6565@pt.cs.cmu.edu>
Lines: 20
Nf-ID: #R:pt.cs.cmu.edu:6565:modcomp:90800005:000:1066
Nf-From: modcomp.UUCP!joe    Oct 24 12:48:00 1989


> Unfortunately, consider the following scenario.  A low-priority process
> is executing inside its critical section.  An interrupt, say I/O
> completion, is serviced and unblocks a higher-priority process.  The
> interrupt handler exits through the dispatcher, which selects the
> higher-priority process based on a preemptive HPF policy.  The
> higher-priority process now executes and tries to enter its critical
> section.  But how can it enter when the low- priority process cannot be
> dispatched and thus allowed to leave its critical section? ** DEADLOCK **

This problem is of course fundamental to the uniprocessor/spinlock
combination (and still exists to a lesser degree on mp's), and is a
primary reason why user-level code should stick to sleep semaphores.

The only safe place spinlocks can be used is in the kernel, where
context switching (and possibly other interrupts) can be locked out for
the duration of the critical section.
--
joe korty			"for every vengence there is an equal and
uunet!modcomp!joe		opposite revengence." (from Cartoon Laws)