1. How does exw and win32lib behave????
- Posted by Hawke <mdeland at NWINFO.NET>
Nov 23, 1998
-
Last edited Nov 24, 1998
whew, this post is going to be rather tough to phrase....
buckle up :)
I am coding a program in win95/win32lib/exw.
This program has many many many simultaneous events
all occuring intermingled.
The program has a 'master' list of data, comprised
of records.
The events that occur may or may not _change_ the
master list, depending on the event.
This post centers around the need to know what happens
during the following potential circumstance:
Event1 occurs, causing windows to react to it, which
will proceed to enter a function (function 1), perform
a task, with part of that task being reading/writing
to the masterlist.
Event2 occurs, causing a different reaction, and the
subsequent spawing/control transfer to func2, which also
requires fiddling with masterlist.
more importantly, event1,func1 AND event2,func2
(even tho they are performaing different 'tasks')
BOTH modify the same record within masterlist.
what i need to know is how win32lib/win95/exw handles this.
when an event triggers (on_timer?for ex.), does it
follow the chain of needed manipulations to data,
_singly_
until that 'task'--that manipulation of data--has
been concluded/reached it's natural ending,
with the second event technically
waiting until event1func1 is actually _done_????
and then, and only then, does event2func2 begin
its manipulations/dancing, even tho _both_ events
occured within the same 'millisecond'??????
the other option would be that event1 and event2
are actually being multithreaded, manipulating
data simultaneously, and if they both happened
to need access to a specific record, then
confusion sets in if event2 needed to update
that specific record BEFORE event1 did, but event1
happened to update first...
so, you say, lock the record?..??...
do i **need** to do this, is my first actual question....
ie: are events processed one at a time, even
those events happening at the "same time" in appearance,
(which is in theory, impossible, as
even multithreaded still means that once
every 200millionth of a second (200mhz)
the processor is *exclusively* handling a specific
opcode, and as such, is *exclusively* handling
a response to an event)
until the "reactions" to one event is done???
or, is there true multithreading at work here
with exw/win32lib/win95????????
here is the other part of my dilemma, and it applies
to events (plural) being handled simultaneously and
as such needing to implement a masterlist record
locking mechanism.
lets talk about THREE (or more) events working
on a record at one time, in the same 'millisecond'....
lets assume that in each & every function, thru-out the entire
program, we have a checklock() done on whatever record
that function will alter.
event1 happens to get to recordXYZ first, just fractions
of a second before event2 gets it's paws on it...
event2 comes along, enters its function, tests the lock
on recordXYZ, sees that its locked and begins waiting...
a loop like:
func func2(masterlistindex:int)
timewaited:real
timewaited = time()
recordXYZ = masterlist[masterlistindex]
while IsLocked(recordXYZ) do
wait(0.1)--seconds
--wait no more than 5 minutes for a lock
if (time()-timewaited)>300 then
return FALSE --couldnt lock, func failure
end if
end while
recordXYZ = lock(recordXYZ) --its mine now...
recordXYZ[thisindex] = 123456
recordXYZ[thatindex] = "smile for camera"
mastlist[mastlistindex] = recordXYZ
recordXYZ = unlock(recordXYZ) --let others have it
return TRUE --func finished successfully
end func.....
looks good????
note: i dont need to lock masterlist itself, becuz, other
functions that are accessing other records wont affect
me, only functions accessing recordXYZ matter...
IsLocked(),lock(), and unlock() are real easy to code...
no worries there...
IsLocked() is mebbe: return thisrec[lockflagindex]
lock() is mebbe: thisrec[lockflagindex] = true return thisrec
unlock() is mebbe: thisrec[lockflagindex] = false return thisrec
no prob...
let's talk about event3 :)
event1 has locked the record...
event2 is in the middle of its
wait(0.10)--seconds
statement...
along comes event3...
it happens to perform its IsLocked() test at time+0.05
from when event2 performed *its* Islocked test...
suppose, at time+0.04 seconds, event1 happened to release said record.
well, event3 will see the record as UNlocked,
BUT, event2 will still be caught in the timedelay...
so event3 locks the file at time+0.06 seconds...
the bogart jumped in line... even tho, by rights,
event2 should have *the next crack at that record*!!!
allright....
we need a queue you say...
that was the suggestion by someone i had talked to about this...
i cant see the pseudocode for this in my head tho...???
what i really cannot see is a way to get around
all this 'nonsense' without both jumping through
a *whole bunch* of hoops AND flat out bogging the
program down with all this
checking/locking/queueing/releaseing .....
just a lot of processor intensive, cache thrashing,
cumbersome, slow, potentially bug ridden code...
'course, if events are handled until 'the bitter end' before
the next event is processed (even tho it gives the
"illusion" of multitasking), then i have no worries :)
it was also suggested, than instead of a queue system,
perhaps a scheduler might be a better option...
i cringe at that one as the whole idea of winsnorz
and programming this way, is that ***ITS*** my scheduler...
heh...
anyone care to comment or discuss this in simplistic
terms that my
'not very experienced in winsnorz goofy details'
mind/knowledge can cope with??
it'd be worth yer time :)
the program
(more... a library almost... sorta...
best explanation is that it is a program, but its
a _generic_ program that addresses a large potential
base of needs, that can be adapted or
*ahem* "included"
like a library...)
is in its very final 'stages' before first public alpha
release... heh, the libraries im building it with
(win32lib...etc) are all 'alpha' in the first place... :)
does that mean that i can never be able to put this
program/library into 'beta' until the libraries that
*i* include become beta??? ;)
and i think that the program/library will be
(crosses fingers) very warmly received...
thanks in advance for any and all laymen comments and
discussions, and any/all translations of 'geektalk'
comments/discussions to laymanism :)
take care all, I hope i havent rambled or babbled...
i tried to form a coherent post... :O
--Hawke'
