Re: Why RosAsm Breaks on a large number of symbols
From: C (blackmarlin_at_asean-mail.com)
Date: 07/12/04
- Next message: wolfgang kern: "Re: ASM vs HLL : absurd war"
- Previous message: Phil Carmody: "Re: ASM vs HLL : absurd war"
- In reply to: Randall Hyde: "Re: Why RosAsm Breaks on a large number of symbols"
- Next in thread: The Wannabee: "Re: Why RosAsm Breaks on a large number of symbols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Jul 2004 07:05:14 -0700
"Randall Hyde" <randyhyde@earthlink.net> wrote in message news:<DrmIc.14027$oD3.2403@newsread1.news.pas.earthlink.net>...
> But GetMessage most certainly returns with data you're not
> interested in, in which case you've got to call it again to
> poll for the data you *are* interested in receiving.
> The only thing that blocking does is make this process take
> longer. But I've never seen a definition of polling that
> prevents the application from being blocked for a while.
>
> Consider the following scenario:
>
> pollloop:
> mov eax, someMemoryAddress
> test eax, 1
> jne polllop
>
> This is polling, no?
> Well suppose now that "someMemoryAddress" is in
> a page of memory that is not swapped in and this causes
> a page fault, and the OS doesn't bother returning until
> some other process actually writes data to that page.
> All of a sudden this is not polling?
I think to consider it otherwise would be to confuse
logical and actual operation -- when we consider the
logical operation of a section of code we ignore such
unpredicatable events such as page faults, preemptive
task switching or hardware interrupts, ie. we consider
the operation of the snippet as if it where the only
thing running on the system (and do not consider lazy
allocation of resources or swapping). The logical
operation of this snippet is obviously polling.
[Oh, and you should place a PAUSE instruction before
the TEST to stop memory order violations, and there are
several other techniques which should be used to stop
the processor clobbering the memory bus in a multi-
processor systems.]
Now if we look at the GetMessage loop, it appears
something different entirely. While it is a polling
loop -- ie. it is executed in a loop which reads
messages and keeps looping until it gets the message
it wants. But, it is also a blocking API -- which
allows the CPU to go off and mess about with other
tasks while waiting for a message (not necessarily
the desired message) to arrive. This behaviour is
definatly not like hardware polling, as a hardware
polling loop can only be preempted by a hardware
interrupt or an event (such as a pagefault, or IRQ).
But, when placed in such a loop the fact the GetMessage
API blocks is not considered as only logical operation
is used to determine whether a peice of code is a
polling loop or not. To see this we look at the logical
operation of the task, which is to read an interface
which will indicates whether a particular event (or
set of events) has occured or not. The salient point,
and what makes this a polling loop, is that the set of
events the programme will continue on is only a subset
of the events the API may return. This is simple to
see when you are checking for zero or not-zero and only
one of these options results in task continuation, but
more complex when the set is larger.
Strangly, if the programme was interested in _every_
event the windows API returned, the loop would not be
polling. So for a piece of code to be considered a
polling loop it would have to...
* Check an external event, which is not controlled
by the task itself, (eg. whether a disk has
completed a write, if a mutex lock has been
released, or if the user has poked the mouse.)
* The code is only iterested in a subset of the
possible events, (eg. if the event can be TRUE
or FALSE the task is only interested in the
TRUE case.)
* The code repeatedly checks the event, if the
event is not one of the subset the programme
is interested in, the code will loop back and
recheck the event. (The interval between
checks is irrelevant and may be goverened by
external events too)
Now when considering the following...
while( var != 0 ) sleep(0);
We can ignore the semantics of the sleep operation
('wait until the specified number of milliseconds
has elapsed, then resume the task'.) While sleep
is a blocking API, and while sleep(0) is noramlly
used to imply a yield(), that does not matter.
Indeed, 'while( var != 0 );' would have the same
logical operation -- and this is clearly polling.
In summary, a loop is said to be polling depending
on its logical operation, not upon whether it may
block or not. (Though polling loops which do block
are noramally better than ones which do not, as
they allow system resources to be used for other
tasks.)
C
2004-07-12
PS: I normally use 'sleep(50)' instead of 'sleep(0)'
-- while a slight delay exists before the loop exits,
this is not normally perceptable. The sleep(50) form
allows even badly written schedulers to schedule
properly while preventing problems with starvation.
When a 'WaitForEvent' blocking API is available, it
is normally better (though the overhead of an OS call
needs to be taken into consideration) and the fact
that M$ implementation of such APIs is othen neither
correct nor consistant across the various flavours
of their system.
- Next message: wolfgang kern: "Re: ASM vs HLL : absurd war"
- Previous message: Phil Carmody: "Re: ASM vs HLL : absurd war"
- In reply to: Randall Hyde: "Re: Why RosAsm Breaks on a large number of symbols"
- Next in thread: The Wannabee: "Re: Why RosAsm Breaks on a large number of symbols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
