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

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 15:39:06 GMT

Frank Kotler wrote:
> 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...

I _would_ dispute it...there's nothing "Bethpolling" about this
at all...I'm using the standard terminology as applied to this
context...

Please, you presumably all have access to Google, yes?

But, yes, Frank...accurate assessment about the terminology
being "less useful", if it causes ambiguity...that's the
opposite intention of the function terminology serves...so if
people are disputing the terminology, then the terminology is
not doing its job properly...

In which case, the terminology is wrong...and may require
"tweaking" to get it back into a position of being a term
everyone sees in the same light...

Mind you, when I said the same thing about "assembler" and "HLL"
terminology and that perhaps adding "hybrid" into the mix would
help, I get either ignored or mocked for doing that...but it's
the same rationale: Terminology is meant to standardise
communication...so if it's causing fights then it's not doing
its job properly...and might need to be "tweaked" to get accord
once again...

But, in this case, hutch demonstrated that he didn't even
recognise that "blocking" wasn't a word I'd made up in any way
but a standard term for schedulers...and that the operation of a
"block" really _DOES_ counteract it being "polling"...

And, really, what I'm saying doesn't contradict the definition
of "polling" - well, not an ordinary sensible one - because when
you're "polling", _YOU_ are looking to see when something
changes...the application _reads_ in a loop until a condition
becomes true (or false, depending on whether it's a positive or
negative test :)...

Whereas, "blocking" is "don't call us, we'll call you"...the
application surrenders the CPU and an _EXTERNAL SOURCE_ wakes
the application back up when a condition becomes true (or false,
depending on whether it's a positive or negative test, again
;)...

And, though a "message loop" could arguably be claimed to be
"polling" for WM_QUIT, there's no reason that it should be
written that way necessarily...this is jumping on a pedantic
point to try to recover from mistakenly not recognising that
"GetMessage" is a _blocking_ API and, thus, _message
retrieval_ - the logical purpose of the "message loop" - is a
non-polling operation when you use blocking API...

> 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...)

I have a distinct problem with notion of "interesting"
message...that's a subjective perspective...only looking at one
iteration of the loop in respect of a particular "interesting"
message...but that's not the perspective of the code itself at
all...the message loop deals with _ANY_ and _ALL_
messages...when we're looking at it as a "loop", we're not
considering in a particular iteration but what is true for _ALL_
iterations...

I mean, you don't look at a "FOR" loop and then state "it's an
infinite loop" because, indeed, the _first iteration_ doesn't
trigger the condition so if we are determining what the loop is
from the perspective of a sole iteration and only "interesting"
iterations of that loop, it's arguably "infinite" from that
bizarre, bizarre perspective...it didn't terminate on that
particular iteration and we're weirdly judging an entire loop by
one iteration of it so it's an "infinite loop"...

A logical nonsense to me...so, yes, I _would_ dispute "what
things are called" in this instance...

Anyway, the message loop does NOT discriminate "interesting" and
"uninteresting" messages at all, typically...it sends them all
to "DispatchMessage" and then the _window procedure_ has the
"big switch" statement that _discriminates_ "interesting" from
"uninteresting"...

And the performance difference between the two is as clear as
crystal by writing one of each and then CTRL + ALT + DEL to load
up "Task Manager" (under NT-based kernels, anyhow) and then
watching the "polling" version eating up every single CPU cycle
it can (sitting on "99%" typically)...while the "blocking"
version sits at _0%_ (until a message is received and processed)
because the application literally surrenders its CPU time
completely, waiting for an _EXTERNAL SOURCE_ to wake it up...

Make the "polling" loop a higher priority - especially
"realtime" - and it so consumes the CPU as to lock everything
out (Windows implements a touch of "fairness", in fact...a
strict priority-based system without this "fairness" introduced
would simply _NEVER_ surrender a high-priority thread to a lower
priority one and it would literally lock up the _entire system_
that only the "reset" button could save you...we get what's
known as "starvation"...again, look up the terminology with
Google...I'm not making it up at all...this is how it works
:)...

Write the code, watch it with "task manager" and try it
out...make it "realtime" and then see if you can manage to get
out of this...but, indeed, don't have anything important unsaved
when you do so, you'll lost it..."starvation" is the weak point
of priority-based systems that high-priority threads can refuse
to give up the CPU and, thus, lock out everything else, if
you're not careful...

And, again, I point out that writing the message loop to wait
for WM_QUIT is a "convenience"...code similar to:

------------------------------------

MsgLoop:
    call GetMessage, &Msg, NULL, NULL, NULL
    call DispatchMessage
    jmp MsgLoop

------------------------------------

Has no condition whatsoever and is - in HLA terms - a "forever"
loop...the termination can alternatively be handled by the
window procedure...it's just a "structured programming" thing
to, you know, "have one entry point and one exit point"...and
make it "neat" that the program starts with "main" and then
terminates when it hits the end of "main"...

And the point here is that the _real thing_ we're talking about
is the _NATURE_ of the "message loop" and message processing in
Windows and so forth...that does NOT operate using "polling", it
uses a _blocking_ scheme...

And - how to emphasise? - "blocking" isn't just "taking longer
to return"...it's a fundamentally logically different
operation...it makes the scheduler marks the thread's "state" in
a different way...the application wastes NO CPU waiting for a
message to be returned...

"Don't call us, we'll call you" is the order of the day...rather
than the application loop around waiting for a condition, it
surrenders the CPU completely setting an "alarm clock" as it
does so...the "alarm clock", so to speak, being set to "please
wake me up when a message is delivered"...

And, I repeat, this isn't about "length of time"...it's a
different _QUALITY_...it's not a "quantity" issue at all...if
there's two messages in the queue then it'll process one in the
first iteration and then, on the second iteration, it'll hit
"GetMessage" and it _won't_ block at all because the message is
already there...it'll return immediately with that message...

[ Well, one Hopes that Windows is optimised to have the sense to
simply avoid the block rather than block and then immediately
unblock straight away...that's a waste of time, of course...you
don't set your "alarm clock" to a point in the past and then
immediately get up the second you've gone to sleep...it's "too
late": just stay awake instead...I'm sure it _does_ have the
sense not even to block - Microsoft are crap coders but not that
clueless, I don't think - but, well, you know...Microsoft don't
let us get a look at the scheduler source code ;) ]

Indeed, if I could only actually see alt.os.development anymore,
then I'd have cross-posted already to do what gone done to Sage
with his "main" assertions...I know Randy looks there
sometimes - as I used when I could - so, really, ask those
who've implemented their schedulers about whether ordinary
message processing is "polling"...

> 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!
> :)

Yes, I have a feeling that this might either be "DOS head
thinking" or that Randy jumped to defend hutch from Rene and
Wannabee but didn't check first whether hutch had actually got
it right...and once you jump from the pan into the fire, jumping
back isn't so easily done...

But, no, maybe Randy does think this is "polling" and all that
stuff genuinely...that would, indeed, just be a touch of
"presumption"...I'm just thinking that if you've taught OS
design on these issues, then you wouldn't be saying things like
that...

It's the way it's being defended: "We're polling for
WM_QUIT!!"...what like a "FOR" or "WHILE" loop is "polling" for
a variable to reach ten? So "generalising" what "polling" means
as to render it useless...

It's a side point and a pedanticism..._CLEARLY_, we're talking
about _message processing_, "blocking API", asynchronous
notification and such...you know, you jump from the pan and then
"awww, crap! I shouldn't have jumped...ummm...ummm...ah, I can
hide behind that! Maybe no-one'll see that I jumped from the pan
if I hide over here behind this big irrelvent point lying
around"...

> 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?"...)

Simply, no...I'd say, anyway...

Linux is a fundamentally multi-user and multi-tasking
system...thus, "Linux specific" is to adhere to that...

Or, alternatively, if you're going to hog all the RAM and all
the CPU and all the disk space...well, doesn't this sound more
like a "bloatware" attitude to the system? Using assembly
language is about using the machine resources as efficiently as
possible...to _least_ "hog" things as possible...to be small
(more diskspace and RAM for other things :), to be fast (more
CPU time for other things, if not used to just do our task
faster in itself :)...or what could really be called "maximising
efficient resource usage" in general to also include using the
maximum CPU capabilities - MMX, SSE, etc. - as well as "small"
and "fast"...that's what assembly language grants and is the
ultimate rationale for using it: To use the system's resources
(all the resources from RAM to CPU time to CPU capabilities to
OS capabilities to whatever is available ;) as _efficiently as
possible_...

_IF_ Linux was single-threaded then, arguably, this is what you
do...BUT there are other applications multi-tasked
alongside...if this were single-threaded DOS, the attitude would
be to "hog" absolutely everything...but as we're "multi-tasking"
then what we're trying to "hog" is the system _FOR ALL PROCESSES
SIMULTANEOUSLY_...do you kind of get what I mean there? _ALL_
running tasks should "hog" the system to use that system's
resources _as efficiently as possible_ to do all their
tasks...consider all the running applications as if it were some
"task group"...you "hog" for the entire group, not just one
application in the group (yes, slightly confused in that you
might not control all of the applications in the group but you
do your best with the bits you do control...ideally, the other
applications would also be written this way too :)...hence, it's
really the same thing if we generalise this idea: in the case of
the single-tasking system, the "group" consists of one task
only...

Ultimately, it's the user that counts...the user presumably is
running all these tasks because they want _all of them_
completed as efficiently as possible...so, to "serve" the user,
you don't "hog" to the detriment of other tasks that they've
started and also want to complete as efficiently as
possible...golden rule: the user _owns_ the machine, no-one
else...

Although, there can be exceptions depending on the "task"
involved...

A game typically "hogs" because, usually, the user is solely
interested in playing the game...you know, it takes over the
entire screen...it's a _DISTRACTION_ from
reality..."escapism"...delibrately uses its own graphics for
screen elements to bring "atmosphere"...a sense of a "virtual
reality"...so to speak, you're playing the game to _FORGET_
about Microsoft Word and your spam Emails for half an hour or
so...hence, it "serves" the user to do as games typically do in
"hogging" and, yes, booting anything "Windows" off the
screen...it would just distract and remind you about Windows and
doing word-processing and spoil the "escapism"...

It's the nature of _what the user wants_ that counts...for
instance, having said the above, if the user is logged into an
instant messenger program while playing the game, it's probably
because they still want to receive messages (indeed, perhaps the
point is that they are playing the game as "something to do
while I wait for John to get back to me with the information"
;)...so - something some games do better than others - it should
still be possible to hear an "alert" and quickly ALT + TAB out
of the game to deal with that and then ALT + TAB back in
afterward...

In the end, this is all being done for the user...so, it's "the
customer is always right" in effect...indeed, a thing that's
always worried me about this industry is the fact that the term
is "user"...a word otherwise reserved for junkies or two-timing
"Love rats"...it's just not conducive to adopting the right
attitude towards them, in my opinion...one nice thing about
computer games in that respect: There's the alternative of
saying "player" instead (but, yeah, it's only slightly
better...after all, a "player" is yet another word with
"unwanted semantics" about being a "Love rat" ;)...

Indeed, perhaps the word should simply be "person"...better yet,
how about this mad idea? Let's call the "LuxAsm user" by an
actual name so that we crystalise the correct attitude from the
off...a bit like "John Doe" or "Joe Public", so to speak...so,
how about if we just call our user "Joe" (exploiting that
"Jo(e)" could also be "Joanna" shortened, so it's "gender
neutral" ;)? Okay, this seems weird at first but I seriously
think it would make a difference...a "psychology" thing...if
you're thinking "the user requires a standardised user
interface" then you do it one way, boring and bland and "Windows
grey"...if you're thinking "Oh, Joe would hate that
colour...nah, let's move that button and make it blue
instead...Joe would prefer that, I'm sure" then you do it a
different way, with cool colours and _useful_ features...the
_correct_ way...because, ultimately, someone called "Joe" may
very well pick up LuxAsm and you really _did_ write it for "Joe"
specifically...ah, you know what I mean, I trust ;)...

Beth :)