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

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

Date: Fri, 16 Jul 2004 17:29:00 GMT

The Wannabee wrote:
> Randy wrote:
> > All I've said is that GetMessage *can* be used in a polling
loop.
>
> No it cant you stpuid fcuk. See Beths post, for better
explaination.

[ "stpuid" = STatic Process User ID, right? And, of course,
infamously, "fcuk" = French Connection UK, who produced a series
of shirts with FCUK written in big, bold captial letters..."hey,
it's the company name, not swearing!" being the cry of
"innocence" from the wearer...very droll "council estate"
humour, I'm sure ;) ]

Anyway, this is an unbelievably trivial pedanticism of language,
really...and, sorry to say, it does smack badly of a "deflection
tactic" from what I can see...liguistical trickery...

All he said was "GetMessage _can_ be used in a polling loop"...

In the same sense that "strlen" _could_ be used in a polling
loop or "xchg eax, ebx; xchg ebx, eax" _could_ also be used in a
polling loop...we _could_ also use MMX or a string of NOP
instructions in a polling loop too...indeed, we _could_ also
wear a beret or cowboy hat, for example, and sing "Wonderwall"
by Oasis, standing on one leg, whilst programming a polling
loop...

This is strictly "technically accuate", 'tis true...

But, of course, the _REAL_ topic here was whether "GetMessage"
could be used _FOR_ a polling loop...to _MAKE_ a loop into a
"polling loop"...whether _"GetMessage" itself_ constituted an
API which "polls"...whether Windows message processing in
general is a "blocking" or "polling" affair...

NOT whether it was a possibility to randomly - and probably
irrelevently just to prove a point - insert "GetMessage" into a
loop that was already a "polling loop", clinging to the claim
that it was only about arguing the patronisingly self-evident
fact that it "could" be present in a "polling loop"...

As English is my first language, then I _can_ tell exactly
what's being said...and - how shall we put it? - though this
line of argumentation is arguably "correct", now that it appears
to have completely changed emphasis entirely...it's, well, not
particularly "impressive"...

> > Some people have mischaracterized polling in this
discussion,
>
> Yes _you_ ! And mostly you, and also Hutch.
>
> > anything to do with the quality of Hutch's code is
irrelevant.
>
> Thats whats started this whole thread, which was spawned as a
result of
> the original thread.

Yes; But how does this explain Randy disputing _my_
"characterisation" of polling and blocking - which he now seems
not to be disputing but was saying the same thing all along,
apparently - when I also stated absolutely explicitly right from
the off that I was _NOT_ in any way commenting on hutch's code
in any way...but was also simply "correcting the
mischaracterisation" that hutch stated (and, last time I looked,
still maintains) that "ALL message loops are polling loops"...

Argued still by hutch, it appears, despite my having clearly
broken that "all" assertion by presenting a case which does NOT
qualify by the "definitions" thus far provided (a 100%
unconditional infinite loop) explicitly...a violation of a most
basic logical principle: How can it be "all" when an explicit
example has been made that is NOT so?

Suspicious, but, granted, not direct evidence of anything, is
the way the phrasiology seemed to _dilute_ once the example was
made and the case was then suddenly "it _COULD_ be used in a
polling loop"...

> > GetMessage *can* be used in a polling fashion.
>
> No it cannot!

Another trivial pedanticism of language here...

You "can" use the return value of "GetMessage" in a "polling"
fashion to look for the termination condition...again, a
linguistical slight-of-hand...

Because the topic self-evidently is NOT about how you might use
the return value...and this is not a particularly convincing
argument because we're "polling" on a variable...hence, for this
argument to stand, an ordinary "for" loop must also constitute
"polling" as the application is looping conditionally on a
variable...

What the topic is _REALLY_ about is whether the _operation_ of
"GetMessage" constitutes "polling" or "blocking"...and in this
regard, Wannabee's quite right:

No, it _CANNOT_ be used in a polling fashion because it _blocks_
(an operation, as I've stipulated, that does not constitute
"polling": Neither the application - NOR even the OS - is
looping around "checking the availability of data" (this
definition of "polling" is flawed, anyway: When "polling" for a
vertical blank, we're looking for a _HARDWARE STATE_ to come
into effect, not any "availability of data"...this is why I've
tried to be more accurate in referring to it as simply being "on
a condition (becoming true for a positive test or false for a
negative test)" - a change of "state" - because there are a
varied amount of "conditions" one could be "polling")...rather
it surrenders the CPU entirely and, instead, the thread which
satisfies the condition implicitly "unblocks" the blocked
thread...it is the converse operation to "polling", basically...

This is important to comprehend because "blocking" can satisfy
almost all "polling" requirements but does so without
unnecessarily consuming CPU resources to do so...

The exceptions (why it is "almost" and not "all" ;) would be a
"real-time" system (which Windows is surely NOT and has never
claimed to be), where as immediate a response as possible may be
required and the latency of the "overhead" of implementing a
blocking scheme is unacceptably long ("blocking" has more
"overhead" but this is a "one time cost", so to
speak..."polling" reacts faster but pays in CPU time constantly
to do so)...

Under Windows, the OS in question, such a "real-time" situation
is highly doubtful and rare...Windows is NOT a real-time system
and things like "page faults" and other numerous factors to its
normal operation rule it out as any reasonable choice for
that...heck, as users of Windows will know only too well, it has
difficulty maintaining "snail carrying a tortoise on its back"
time, let alone being a reasonable and valid "real-time"
system...indeed, to say it reacts "lazily" to operations is
almost offensive in its understating of the reality...

Another exception would be a single-tasking system...well, sort
of...the point here is that it actually often doesn't matter one
way or the other how you implement things on such a
system...there are no "other threads" so if the sole thread that
does exist "hogs" the CPU for "polling" then it's, well,
irrelevent...the only considerations here, in fact, are about
incidental things to the actual application itself of the CPU
heating up and that kind of thing...note, though, that using
"blocking" rather than "polling" is _STILL_ a perfect
possibility on such a system...if the "overhead" and "latency"
of the scheme isn't a problem...

Again, Windows is a multi-tasking system so this particular
exception was irrelevent to the specific discussion about
"GetMessage" - a Windows API call - and Windows' operations...

Yes, "blocking" schemes are no panacea...when there are
"real-time" requirements for a superfast response that can't
tolerate sitting around for the scheduler "overhead" of
unblocking threads and that kind of thing, then "polling" must
often be used...

BUT, generally speaking, "blocking" is the preferred option (and
is why any reasonable multi-tasking system implements this
fundamentally into its design and operations :)...for the minor
price of that "one time cost" overhead (when you _can't_ pay
this price, as the "latency" would be unacceptable is the
exception where you consider "polling"...but this is the rare
exception, not the rule, as only "real-time" systems have such
strict timing conditions and, even then, it has to be a very
strict timing condition involved, if this price cannot be
acceptably paid), it can do all that "polling" could achieve
without consuming CPU resources doing so (and as we're talking
"multi-tasking" systems here then whatever CPU time our threads
"releases" can be used by other threads to do other tasks)...

> > As your
> > inexperience in computer science is generally quite obvious
> > and English isn't for first language, it's understandable
that
>
> That my dear professor should read :
> "English isn't _your_ first language"
>
> Glad to be of assistance.

Ah, be fair...one should make a distinction being a "typo" - a
_manual_ typing mistake, totally physical in origin (typically
just a tmeporarily "slip" of brain-to-hand co-ordination ;) -
and a "slip" - a mental "typo", so to speak, where, say, a word
is temporarily confused for another (e.g. I'm constantly typing
"allow" when I mean "always" or "always" when I mean "allow"...I
just keep doing this all the time...though, I might catch it and
correct it before sending often that you might not realise just
how "often" I actually mean here...and, no, I have no idea
why...it's some mental glitch or something ;) - and that of
actually not knowing the English language...

Randy's written enough stuff to demonstrate that he knows the
above wasn't right...so it must just have been a physical or
mental "typo"...looking at where "yo" and "f" are on a QWERTY
keyboard, then the odds favour it being a minor "mental typo"...

You must really learn to calm and relax, Wannabee...a minor
disagreement here and there on technical or political issues or
whatever doesn't really constitute taking some "vow" of
obsessive "vengence" on a person to destroy anything and
everything related to them, on some bizarre "vendetta"..."oh, he
made a typo: Kill! KILL! _KILL_!"...

I mean, let's get things into perspective here, please...and
that's "friendly advice" that, in fact, the entire newsgroup can
take (yes, including me once in a while ;)...it's weird, isn't
it? Why does USENET provoke this bizarre "vendetta" behaviour in
practically anyone who comes near it? Doesn't matter how
normally "calm" and "understanding" you might normally be, as
the second you come into contact with USENET, then it's only a
matter of time before you end up in the middle of some "intense"
thread 27 levels deep, swearing "vendetta" on some trivial point
of irrelevent mineutia...it's, ummm, the power of the internet
or something ;)...

Beth :)