LR> So what is VX Works?  I know UNIX can be tuned to handle Real-Time

VxWorks is a real-time operating system produced by a company called Wind
River Systems.  It features a microkernel named "Wind" and very
low interrupt latency times.  It is typically used in embedded computing
applications, often in military systems but also for tasks such as process
controllers and data acquisition systems.  In the 1991-92 timeframe I did
several months of programming on systems that used VxWorks including a
prototype military communications network system (non-classified, of
course, or I wouldn't be mentioning it) and helping port X11R4 (or was it
X11R5? -- can't remember at the moment) X Windows server to run on VxWorks.

VxWorks has a C language API that is very much like the typical C language
API used for Unix programming.  It has TCP/IP communications features, lots
of different types of semaphores (event, counter,mutex, mutex with priority
inversion protection) and other nifty features.  It also has what in my
opinion is a major mistake -- the lack of memory protection.  Wind River
Systems says that adding memory protection would add overhead to program
execution.  My opinion is the overhead is well worth it when you've got a
bug and there are 30-40 tasks executing concurrently in your system and you
can't figure out which one is taking down the entire system.  Besides, the
overhead usually isn't that much and usually will not interfere in any
meaningful way with determinism for most applications.  The best of both
worlds would be to provide an option to rebuild the microkernel for both
protected and unprotected memory models depending on the needs of the
system and the application developers.

I don't agree that Unix can be "tuned" to handle real-time
applications.  That is too vague of a statement.  It is like saying that
airplanes can be tuned to fly past Mach 3.0.  There are many Unix
implementations, only some of which are suitable for real-time
applications.  Many (if not most) Unix implementations feature monolithic
kernels with potentially large interrupt latency times. Sometimes these
have even been on the order of 100ms guaranteed maximum interrupt latency. 
Such systems are certainly not suitable for real-time applications.

 LR> applications but can OS/2 be tuned to handle Real-Time
 LR> apps.  Can either be done without the source for
 LR> either operating system?

Yes, OS/2 applications for real-time process control and data acquisition
can be written.  OS/2 gives fairly low interrupt latency times and provides
mechanisms for prioritizing thread scheduling that will meet the needs of
many real-time applications.

 LR> Right now I don't see how anyone can, in a reliable
 LR> manner, assure any client that either of these
 LR> operating systems will meet their REal-Time process
 LR> control needs without the very real option of
 LR> modifying the operating systems involved - as necessary.

I don't see how you can assure them that any operating system can meet
their needs unless you sit down and figure out a rough flow diagram for the
system, decompose it into tasks, determine what tasks get what priorities,
estimates required response and processing times, and then pick some target
hardware that will allow the selected OS to provide the responsiveness and
performance that you need.  You should also be sure to estimate very
conservatively about responsiveness requirements and build some performance
margin into the hardware you pick.

 LR> 'C' was supposedly written to allow development of
 LR> operating systems.  I think I can agree this can be
 LR> done with 'C' but not with time critical systems like
 LR> Real-Time process control where high speeds are
 LR> crucial and where memory constraints may exist.

You haven't given enough detail to determine whether OS/2 (or VxWorks,for
that matter) would be suitable for your real-time application. For
instance, if you are going to build a real-time targetting system for
aiming X-ray laser bursts at outbound missiles, VxWorks running on a
SPARC-2 board wouldn't cut it.  You would likely need interrupt latency
times of several magnitudes smaller in order to be able to adjust
everything and hold the machine together until the nuclear blast blows it
to bits, thus generating the X-ray laser blasts.  Of course, this
discussion omits the important details like whether such a machine could
ever be built even if you had infinitely small interrupt latency times.

Now if you are instead trying to build a more mundane real-time system such
as a chemical process control system, interrupt latency times of even as
high as several hundred milliseconds may be OK, depending on what your
system is supposed to do.

Another consideration is the consequences of a delayed event response. Now
if you are writing a data acquisition system, perhaps it means you loose a
small amount of data.  But if a data update is going to be sent at regular
intervals often enough to meet your needs even if you miss every other
sample, maybe that doesn't matter.  On the other hand, if your real-time
system is maintaining the flight control systems for a forward swept wing
aircraft and the computer fails to respond to an important event in time,
the entire aircraft could disintegrate in midflight in less than a second,
killing the pilot and wasting potentially hundreds of millions of dollars
of DoD money.

 LR> C++ is even slower in execution times and even compilation times than in
 LR> 'C' from what I have heard so why would anyone
 LR> consider doing Real-Time work in anything but
 LR> assembler?  Anyone care to share their experise,
 LR> insights, etc..  Thanks much.

C is a much simpler language than C++ -- it lacks operator
overloading, type inheritance, access qualifiers (public,
private,protected), and many other features.  So it is no wonder that a C++
compiler is in general slower than a C compiler.  But C++ *is* C if you
don't use these featues -- the rest of the language is pretty much
unchanged from ANSI C.  Therefore the only argument you can make about
slower execution times from C++ is along the lines that new language
features are not compiled as efficiently or in some cases inherently take
more time to execute.  For instance, virtual function resolution takes a
bit more time than a non-virtual function call.

I would not state across the board that C++ is slower at execution time
than C.  It may be slower for particular programs and with particular
compilers, depending on the maturity of the compiler and its run-time
libraries and the quality of its optimization.  But it is readily possible
to write a very slow program in C.  And it is possible to write a fast
program in C++ -- you can use inline functions and other features that ANSI
C does not have to help you in this effort.

However, even if you said that C++ is certain to be 100% slower at
execution speed than C, that would not mean that C++ is worthless. There
are plenty of arguments for C++ along the lines of code reuse and more
rapid program development once the programmers get up to speed on C++ and
use its features fully.

Finally, you are missing the point of real-time.  Real-time does not mean
blindingly fast performance, it means that execution timing is part of the
"correctness" of the program.  For instance, responding to a
change in a sensor output within 5 seconds might be a real-time response
requirement, but if it only takes 50 machine instructions to generate this
response then you might even be able to pick a slow 8-bit microcontroller
for your run-time hardware depending on the other application requirements.


--- Maximus/2 2.01wb