PH>Basically, the use of C++ has negligible impact on the
 PH>performance of your real-time system since the only performance
 PH>overhead incurred is when using C++-specific features such as
 PH>virtual functions and object construction/destruction.  None of
 PH>the C++ features cause response/run-time to become
 PH>indeterminate, just a little longer.

This isn't true.  C++ constructors and destructors can easily cause
indeterminate execution profiles.  If you preallocate data structures that
takes care of most of the problem as long as you aren't allocated so much
storage that you cause virtual memory paging during execution of the
time-critical routines.  If you are really concerned about this
possibility, there are ways that OS/2 can lock small amounts of memory so
they will never be paged.  This can be done from device drivers,for
instance.

In general, in any routine that must perform time-critical work you should
never allocate memory using OS/2 or C/C++ library routines. Keep the
time-critical routine as simple as possible, moving the setup and teardown
work outside of it.

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

Indeterminate in this context means that you cannot state an upper ceiling
for execution time.  I ran into big problems last year with memory
allocation routines in C Set++ being extremely indeterminate because I was
allocating and deallocating memory on multiple threads. The heap is mutex
protected by a single semaphore.  The result was that I was having problems
with time-critical threads being blocked and loosing data because they were
waiting around for heap access and additional I/O buffers couldn't be
allocated until they got mutex on the heap which was taking long enough
that data was being lost.  The solution was to preallocate more I/O buffers
than needed and to write a non-blocking buffer allocation routine that used
486 atomic test-and-set, test-and-reset, increment, and decrement
instructions.  I made these routines SMP safe by LOCK prefixing the atomic
instructions in expectation that we will eventually be running this
software on SMP hardware using OS/2.

 LR>     So what you said above is based on theory, or fact?  Based on
 LR>     experience with C++ in serious time critical (a few microsecs or
 LR>     less) Real-time process control, Peter?

The above observations of mine are based on personal experience.  Just
about any language can be used for real-time programming, but you have to
pay a lot of attention to maintaining determinism in the application
design.  You cannot just assume that new, delete,malloc(), free(), and
other basic library routines are going to be deterministic.  For example,
these routines internally use semaphores and can also cause virtual memory
paging.  Both of these situations are essentially indeterminate in their
execution profiles -- you can't easily predict how much time they will
take.  Sometimes they might take 0.1 milliseconds, other times they may
take 120 milliseconds, and in extreme situations they could even take over
a second to complete.

I don't think OS/2 is suitable for applications that require response times
on the order of a few microseconds.  Frankly, I'm not sure if VxWorks is
even suitable such applications.  If you are looking at such quick response
times, you may have to build custom hardware or add additional dedicated
CPU's to your system to handle the most time-critical events.  On the other
hand, you may be overestimating the need for time-critical responses. 
Reality might be that response times of 10-20 milliseconds would be fast
enough and in this case OS/2 might be suitable and VxWorks definitely would
be.  But without having any clue of what you are doing, I don't know.


--- Maximus/2 2.01wb