Mario Semo wrote in a message to Mike Bilow:

 MS>> I'm interested in semaphores which are avail in the next
 MS>> 10microSecs.  

 MB> This can never happen.  If your process is not actually 

 MS> simple wrong. 

 MS> // query old prior if you want
 MS> DosSetPriority(timecritical,0) // not really required. just
 MS> in case.
 MS> DosAsyncTimer(10ms, hev)
 MS> DosWaitEventSem(hev)
 MS> DosSetPriority(old prior)

 MS> comes within 10ms. 

First of all, there is a pretty big difference between 10 MICROseconds as
you originally specified and 10 MILLIseconds as your code example attempts.
 Further, even 10 MILLIseconds is pushing it, since you are always subject
to the scheduler granularity of 32 ms, in which case you will be scheduled
on average in 16 ms although worst case remains 32 ms.

 MB> Even a fairly fast system would be hard pressed to handle a 
 MB> hardware IRQ within 10 us, although this is probably quite 

 MS> I'm doing 57.6 KB comminication with a controlling system
 MS> (of a large chemical industry process) and they (its on one
 MS> my customers systems) emulate a 'token ring' based on
 MS> loop'ed async connection. When the token is on my machine, i
 MS> have 11ms to react - else the token is going to the next
 MS> machine - and i have no problems with this one. i'm neary
 MS> never missing the token. 

 MS> running on at least 75MHZ systems with 32MB mem only the
 MS> machine is even not really busy doing all this stuff. pulse
 MS> is near 0. 

 MS> on the other hand, running on only 33MHZ system, it is also
 MS> working, but pulse is at 100%. 

Wait a minute... an IRQ response is NOT subject to the scheduler
granularity, and can certainly be a matter of microseconds rather than
milliseconds.  As you note, a lot of networking and communication hardware
depends upon response in this general range.  This is a very different
matter from something like an async timer semaphore, which is subject to
scheduler granularity.

 MB> time, I think that the most optimistic possible response 
 MB> under OS/2 is probably around 5-6 us.

 MS> thats sounds correct. The above code with DosAsyncTimer
 MS> response in about 7.3ms in 95% of all testcases. 

 MS> PS: DosSleep of course will never return in <= 31ms. even
 MS> not in TimeCrtitcalThreads. 

This is not quite right.  DosSleep(1) will return more quickly than
scheduler granularity if and only if no other threads are ready, or all
other ready threads make explicit yields.  My guess is that this is how you
are seeing 7.3 ms as your 95% threshold.  I think you would see your
response time decline to a normally distributed curve centered on 16 ms if
the processor is loaded.
 
-- Mike


---