🚀 go-pugleaf

In article <41irqv$t83@usenet.ucs.indiana.edu>,
scott goehring <sgoehrin@copper.ucs.indiana.edu> wrote:
> time spent servicing _any_ interrupt is time that can't be used for
> computation.  it may not seem like much, but in a time-critical
> (i.e. real time) application, it can be.

Unless the interrupt has work to do (in which case you need to do the
work regardless) the cost of interrupts is negligable. The exception is
when interrupts are coming fast enough to flood the CPU. More on that
in a second.

Real time operating systems, however, are almost all preemptive. The only
ones that aren't are those tiny real-time executives that run in toaster
ovens and the like, where the job is simple enough it's practical to do
polling.

And speaking of polling, that's the only alternative in a cooperative system
to handle frequent events. Polling systems break down much quicker under
overload conditions than interrupt-driven ones. Long before your CPU collapses
under interrupts, your polled system would have given up.

> you don't _have_ to put in yield calls.

Only if you want interactive response, like, for example, Windows.

> i used to work for a company that occasionally contracted out to
> Boeing Computing Services.  as i recall, their Y-MP used a limited
> preemption scheduler; preemption only occurred if a higher priority
> job entered the queue.

That's not a "limited preemption" scheduler. That's how all preemptive
systems work. It's just some adjust the priority of jobs automatically.

That is a completely separate issue from cooperative versus preemptive.
-- 
Peter da Silva    (NIC: PJD2)      `-_-'             1601 Industrial Boulevard
Bailey Network Management           'U`             Sugar Land, TX  77487-5013
+1 713 274 5180         "Har du kramat din varg idag?"                     USA
Bailey pays for my technical expertise.        My opinions probably scare them