Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions

From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 07/18/04 

Date: Sun, 18 Jul 2004 17:24:14 +0200

Randall Hyde wrote:
> "Herbert Kleebauer" <klee@unibwm.de> wrote in message
 
> Strange, it's the one that OS textbooks use.

No, you just misinterpreted it.

> Polling is simply a programmed-I/O mechanism for
> checking for the availability of desired data. In the
> I/O definition space, the three definitions that are grouped
> together are {polling, interrupts, DMA}. "Blocked" isn't
> a part of this group.

Polling can be used with a CPU which doesn't support
interrupts at all. If you use a method to check for
external events which doesn't work without interrupts,
then it is not polling.

> > > Polling loops continue looping and testing a condition
> > > until an external event occurs
> >
> > That's correct. But "call api_sleep, 50" does not "continue",
> > so it's not polling.
>
> ????
> It most certainly does continue, after (at least) 50 units of time have
> expired.

There is no way to measure this 50 time units without
interrupts, so it's not polling. If "call api_sleep, 50"
would be only a simple waiting loop (which works
without interrupts) then it would be polling, but then
you would also have 100% CPU usage in this polling loop.

> In particular, the fact that Sleep returns after some period of time in
> no general way indicates that data is now available. The program
> must still poll the status to see if such data is available. There is no
> interrupt telling us that data is available, and the data wasn't
> automatically
> moved to the appropriate place via DMA. So the notification is still
> via polling in this example.

That doesn't matter. The essential thing is, that the return is
interrupt driven (timer interrupt).

> > But this is the wrong explanation. With this
> > argumentation a polling loop which only reads a
> > single bit (e.g. the BUSY line of the printer
> > interface) can't be a polling loop, because it
> > is interested in "_all_ permutations of the
> > external event -- not a subset" (there is only
> > one bit).
>
> His explanation is quite correct. However, if
> GetMessage provided only *1* result (as you would
> get with a single bit), then this would not be a polling
> loop, since GetMessage would block until the
> data you're interested in comes through;

Now you are telling me, that, if you are using a
printer in polling mode (where you test the busy
line in a loop until the next character can be sent)
then this isn't polling at all because only a single
bit is tested?

> > > But, this is a polling loop...

> > Depends on pause. If it is just a programmed
> > waiting loop, then it is polling, if pause releases
> > the CPU, then it is not polling.
 
> If it's not polling, then notification of the I/O event
> must be controlled by an interrupt

As I said above, a programmed waiting loop does not involve
interrupts and therefore is a polling loop. But if
the CPU is released, a return is only possible with
an interrupt and therefore it is not polling.

> > > Remember...
> >
> > > * A polling loop will only be interested
> > > in a subset of the events which will can be
> > > signaled by the device / task.
> >
> > No (see above)
>
> A "poll" is simply a programmatic check to see
> if some data is available or an event has occured.

Yes, "a programmatic check" and not interrupt
driven. The return from "GetMessage()" is
interrupt driven.

> > The main difference between polling and not
> > polling is the use of CPU time to get information
> > about external events.
>
> No, this is not true.
> Though polling most certainly uses the CPU to
> evaluate status to determine if an event has occured,
> it is also true that an interrupt notification *also* uses
> CPU time.

It uses CPU time for reading the event but not for waiting
for the event.

> > As an example let's take a loop which continuously
> > calls int 1a to read the timer value until a
> > certain amount is elapsed. If you execute the
> > loop in real mode DOS, this loop will consume
> > nearly 100% CPU time an therefore is polling. The
> > same is true if you execute the code in Win9x. But
> > the same code executed in W2k/XP will consume nearly
> > no CPU time and therefore isn't polling (W2k suspends
> > the task until it updates the timer variable).
>
> But when W2K/XP updates the timer variable and
> starts your process, it reads the value returned by INT 1A
> and decides whether to loop back and try it again.
> That's still polling, even if it doesn't take place quite as often.
> Now had the process called "sleep", rather than polling the
> timer, that would be a different matter.

Polling regards to waiting for an event and not processing
of that event. If you are notified of an event and decide
you are not interested in this event so you wait for the
next event, than this is part of processing of the event
and is independent whether you get aware of the event by
polling or by interrupt.

> > A polling loop doesn't need interrupts to work.
>
> Depends on the loop. Consider the following
>
> pollingLoop:
> mov al, SomeMemoryVar
> test al, 1
> jz pollingLoop
>
> This polling loop *does* depend on interrupts to work,
> as there has to be an ISR or some other process that
> writes data to "SomeMemoryVar" so that this loop will
> exit.

No, not the polling depends on interrupts, but the
generation of the events. The polling still works
without interrupts but it never finds an event it is
waiting for.

 
> > If
> > in the above program in Win2k Interrupts would be
> > disabled, then it would become a polling loop with
> > 100% CPU usage as in Win98.

This statement is wrong. First I had a different example
and when I modified it to "int 1a", I forgot to delete
this sentence.

> > A call to GetMessage()
> > would never return without interrupts (no task
> > switch without interrupts) so it can't be polling.
>
> I don't know the internal operation of GetMessage that well,
> but there is no reason GetMessage would require an interrupt
> to return to the user. If there are already some messages sitting
> in the queue (which could have been placed there by the current
> application), GetMessage should return right away with the
> message at the front of the queue if the current process still has
> time available.

Yes, but it has to work not only in one example, but in
any case. And without timer interrupts there would be
no task switch.

> Some simple definitions:
>
> Polling - the CPU explicitly reads a status value to determine
> if an event requires processing by the process. The process'
> own instructions are responsible for executing the instructions that
> do this test.
>
> Interrupt-notification - An application arms an interrupt that
> triggers when an event requires processing by the process.
> The process' signal/interrupt handler activates when the
> interrupt occurs.

No problem with this definition. It clearly states that
GetMessage() is not polling but interrupt driven.

Relevant Pages