CS> PH>Basically, the use of C++ has negligible impact on the
CS> PH>performance of your real-time system ...

CS>This isn't true....

CS>time-critical routines.  If you are really concerned about this possibility,
CS>there are ways that OS/2 can lock small amounts of memory so they will never
CS>paged.  This can be done from device drivers,for instance.

How small?

CS> LR>     "Indeterminate", perish the thought.  :)  You
are beginning
CS> LR>     to sound like a mathematician instead of a engineer who
CS> LR>     usually *presumes* there exists unique solutions to most if not
CS> LR>     all problems.  :)

CS>Indeterminate in this context means that you cannot state an upper ceiling f
CS>execution time.

I think Peter gave me a similar definition as well, Craig

Would it be clearer, and more comprehensible, to state that
"indeterminate" means that it can not be determined, with any
specific certainty, (a unique mathematical solution) due to the varying
length of internal computer process times that might occur such that
any particular response will be (to a certainty) *within* the given
timing specs (time domain) for responding to a certain (digital - A/D)
stimulus?

When I read your definition I tended to be puzzled.  The puzzle was in
trying to understand your meaning as to *why* an "upper ceiling
execution time" could NOT be stated.

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

In other words it seems to me that stating a "upper ceiling execution
time" cannot be stated is somehwat vague in that it doesn't fully
qualify that a specifc outer timing domain does exist in most RT apps -
and that specific domain time must not be exceeded - by specification.

And that "indeterminate" means that response time MUST be *within* that
specific timing domain or that response will be invalid.  Would you
agree with that what I have just said might be clearer - if more wordy
- for the uninitiated?

What also might not be clear to the uninitiated is why responding
(D/A) to a (Analog to Digital(A/D) stimulus within that specific time
domain would be viewed, even if it was not a constant response time to
the same stimulus, as being valid?

Would you care to address this issue, Craig?

CS>I ran into big problems last year with memory allocation
CS>routines in C Set++ being extremely indeterminate because I was
CS>allocating a deallocating memory on multiple threads.

You mean dynamic memory allocation on the heap, right?  What does
extremely indeterminate mean to you, Craig?

CS>The heap is mutex protected by a single semaphore.

I am not familar with the "mutex" term relative to the heap.
And I can never remember what a semiphore is tho I have run into it
enough.  Could you please explain both as you use them here.  Thanks.

CS>The result was
CS>that I was having problems with time-critical threads being
CS>blocked and loosing data because they were waiting around for
CS>heap access and additional I/O buffers couldn't be allocated until
CS>they got mutex on the heap which was taking long enough that data
CS>was being lost.

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

CS>The solution was to preallocate more I/O buffers than needed and to
CS>write a non-blocking buffer allocation routine that used 486
CS>atomic test-and-set, test-and-reset, increment, and decrement
CS>instructions.

What is "486 atomic test-and-set" and how did you use this from C++?

CS>I made these routines SMP safe by LOCK prefixing the
CS>atomic instructions in expectation that we will eventually be
CS>running this software SMP hardware using OS/2.

Could you make this a little plainer for those of us who are not
intimately familar, as you are, with C++ and OS/2?  What is SMP for
instance?

CS>any language can be used for real-time programming, but you have to pay a lo
CS>of attention to maintaining determinism in the application design.

Could you explain why this is so?

CS>You cann
CS>just assume that new, delete,malloc(), free(), and other basic library routi
CS>are going to be deterministic.

You mean they will be "indeterminate"?

CS>For example, these routines internally use
CS>semaphores and can also cause virtual memory paging.  Both of these situatio
CS>are essentially indeterminate in their execution profiles -- you can't easil
CS>predict how much time they will take.  Sometimes they might take 0.1
CS>milliseconds, other times they may take 120 milliseconds, and in extreme
CS>situations they could even take over a second to complete.

That sounds indeterminate to me if the "upper ceiling execution time"
for the response time must be determinate and it is found not to be
determinate.

CS>I don't think OS/2 is suitable for applications that require response times
CS>the order of a few microseconds.  Frankly, I'm not sure if VxWorks is even
CS>suitable such applications.

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

CS>If you are looking at such quick response times
CS>you may have to build custom hardware or add additional dedicated
CS>CPU's to y(our) system to handle the most time-critical events.  On
CS>the other hand, you may (be) overestimating the need for
CS>time-critical responses.  Reality might be that response times of
CS>10-20 milliseconds would be fast enough and in this case O might
CS>be suitable and VxWorks definitely would be.  But without having any
CS>c??? of what you are doing, I don't know.

Craig, it is possible the client won't need microsec response times.
I can't determine this right now, nor give you specifc information on
the actual circumstances for this application.

Regards, -= Lou =-


--- WM v3.10/91-0154