🚀 go-pugleaf

In article <id.T8WM1.5V2@nmti.com>, Peter da Silva <peter@nmti.com> wrote:
>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.

   I hate to disagree with a fellow Amiga owner, but there are 'real-time'
applications that use polling as a means of controlling the admitted
workload AND a means of maximizing CPU utilization.  Both the 1A ESS(tm)
and 4ESS(tm) switches primary processors use a non-pre-emptive cooperative
control, similar to a threaded/message-passing mechanism.  Since each
'process' only handles a limited amount of information (1 call, a few
I/O translations, etc.) before 'yielding', there is no need for pre-emption
except as an error mechanism to handle run-away software.

   The 4ESS switch does not use interrupts at all, except for error handling
and to check that a few routinely-scheduled tasks are actually running.
(Hardware can schedule a task to run - the 'yielding' is actually an option
built into the 'return on stack' instruction, so it costs nothing to test
if such tasks are waiting.)

   The 1A ESS switch requires some interrupt-driven tasks because incoming
digits (dial pulse and tone) are scanned in and/or sent out by main processor
software.  Dial pulse (10 pulses/second) requires the line be monitored for
on/off-hook state changes at least every 25 milliseconds.  But each digit
doesn't cause an interrupt; instead, a single timer interrupt occurs every
5 milliseconds and polls the appropriate scanners.  By using polling,
overload is actually handled very smoothly -- the rate that lines are
scanned for new off-hooks slows down as other load increases.  Interrupts
on a per-line or per-digit basis would never allow a 2 MIP processor to
handle 300,000 calls per hour (1A ESS).

   Of course, today's telephone switches could be considered as very
large 'toaster' projects, since the software is tightly coupled in both
design and execution.  For 'multi-user' applications and general-purpose
computing applications, the right thing is usually to use interrupts
[and DMA :) ] as the primary I/O mechanism and a pre-emptive scheduler.
On single-user systems, one can get by with non-pre-emptive scheduling,
just like one can get along without DMA, but it's a pain and it doesn't
scale well.

Al Varney