In a message on 09-18-94, Louis Rizzuto said to Craig Swanson:

LR>For instance, what came to my mind was the thought that one could
LR>just note when a stimulus occurs and then simply wait for the longest
LR>response time - empirically - and that could be the "upper ceiling
LR>execution time" to be stated for a response.

If your customer (in general) will accept a system which has been put
together using empirical measurements to "ensure" its correct operation,
you are not dealing with a "hard" real-time system.  The problem with
measurement is you can't be sure that the very _next_ sample, the one
you didn't look at because you decided to stop measuring, will not be
twice as long as the longest one you've seen to date.  If you have hard
timing requirements you _must_ be able to specify an upper limit to your
response, via analysis rather than measurement.

The only time measurement is suitable from confirming the operation of a
"hard" system is if you have first identified the worst-case
"path"
(series of statements that will be executed) for a given response.  You
then set up a test which measures the length of that worst-case path and
the result is your "upper ceiling" time.  When we talk about determinism
in this respect we are really just saying that we can identify this
worst case scenario.  Whether we measure or analyze it to find its
duration is irrelevant.


LR>Why were the time critical threads being blocked (delayed)?  Doesn't
LR>OS/2 give priority to time critical threads in an appropiate manner?

"Time critical" under OS/2 refers only to the priority class.  A time
critical thread always preempts a lower priority thread, if both are
ready to run.  If, however, the time critical thread wants access to a
resource that the lower priority thread "owns" (via a semaphore) it will
be blocked (made not ready to run) until the lower priority thread has
relinquished ownership of that resource.  When that happens, the time
critical thread will _immediately_ begin running (preempting the lower
priority thread) but until that happens the time critical thread doesn't
get to run at all.

LR>Someone told me that 400us + about ten instruction cycles is the best
LR>interrupt latency time for time critical for OS/2.               ^^^^

Not "best", Louis, WORST!  The designers of OS/2 attempted to guarantee
that your interrupt latency will never be _longer_ than that value.  It
is not meant to be a precise value in any way, so your "ten instruction
cycles" is meaningless.  Most of the time it will probably be more like
50-70 microseconds and sometimes it might even be a tad over 400
microseconds.  Nobody's stopping a device driver writer from going
berzerk and locking out the system for that long.

Peter Hansen  ***  Engenuity Corporation  ***  Guelph, Ontario, Canada
Internet: peter.hansen{at}canrem.com    RelayNet:->CRS    FIDO:(1:229/15)
___
 * MR/2 * ***  Learn Esperanto, the international language.  ***

--- QScan v1.12b / 01-0348