> > What has to happen is either:
> > 1) A process wakes up a higher priority process
> 
> A process can't (in unix) wake up another process -- it can only ask the
> kernel to, and at that point it's the kernel which decides what runnable
> process will actually run, not the signalling process.  (Unless some
> extended API (system call) that I'm not aware of gives an application a
> direct hook into the scheduler.)
> 
> > 2) An interrupt wakes up a higher priority process
> 
> A hardware interrupt, at least in Unix, can normally only "wake up" the
> kernel so far as I know....

The (kernel) code running from either a syscall or hardware interrupt
can call wakeup() (or whatever netbsd calls it) to unblock a process
stopped on a kernel sleep() (tsleep?).

> > On an SMP system an interrupt on one CPU might cause the scheduler
> > to generate an inter-cpu interrupt to force a different cpu to
> > process switch....
> 
> Hmmm... that's something I hadn't really thought deeply about (one CPU
> interrupting another).  I've studied relatively few SMP hardware
> architectures down to that level -- is such a capability commonly
> available on modern multi-CPU systems?

I've not actually written that bit of one!  However IIRC the inter-
CPU interrupt was vital for a variety of things - mainly low level
stuff (someone else mentioned TLB shootdowns).

I only remember it being there (and some of how it requested the
other cpu to do things) not what the actual requests were.

	David

-- 
David Laight: david@l8s.co.uk