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

From: Frank Kotler (fbkotler_at_comcast.net)
Date: 07/14/04 

Date: Wed, 14 Jul 2004 17:30:58 GMT

Randall Hyde wrote:

> No doubt, based on the arguments in other threads, some
> people are going to continue to argue that all calls to
> GetMessage are "interrupt-driven" rather than "polling."
> Unfortunately, such opinions are *not* supported by
> definitions found in common architecture, OS, and
> machine organization text books.

I won't dispute your expertise on "what name things are called by", but
ISTM that if these two vastly different situations are called by the
same name, the terminology is less useful than it might be. Hutch has
suggested "Bethpolling" - I think "pure-polling" and "blocking-polling"
might be more descriptive...

It's true that "blocking-polling" wastes some cycles on uninteresting
messages, but it's only "one iteration's worth" per message. A
"pure-polling" loop (like "Hutch's loop", or a messageloop that did
"call PeekMessage/cmp eax, NO_MESSAGE_AVAILABLE/ jz top" continually)
would waste *far* more cycles. (This assumes that a message is *not*
available "most of the time" - is this untrue?) From the viewpoint of
the application, there isn't much difference, but to another task that
could be using the CPU time given up by "blocking-polling", it's a *big*
difference! (the exact difference would depend on the
available:unavailable ratio and on the interesting:uninteresting ratio,
I suppose...)

This feels really weird to me. I'm almost tempted to accuse you of
"thinking like an old dos-head" - and that's supposed to be *my* role!
:)

In any case, this discussion prompts a philosophical question for the
LuxAsm team... If it were possible to speed up LuxAsm by being
"inconsiderate" and hogging resources, would this be an acceptable
method of speeding up LuxAsm? (I suppose the answer depends on "how
much?"...)

Best,
Frank