>>>>> "John F Woods" writes:

John> as I said before, anyone who naively thinks they can put two uncoordinated
John> "real time" tasks on the same processor just doesn't understand real-time
John> systems.  If you have two real time tasks each of which needs a particular
John> guarantee of responsiveness, then you design them together to ensure that
John> both of their guarantees can be met.

	I think everyone is throwing around "real-time" a little too
loosely and ambiguously here.  Is the worst that will happen if the system
does not meet its commitments that you drop a frame or the robot arm goes
through the wall?

	For extremely hard real-time, one precalculates a fixed schedule
among cooperating tasks and each task had better get its work done in that
allotment.  As soon as you talk about dynamic scheduling, you already have
moved out of one realm of real-time OS work.  These strawman arguments are
irrelevant unless you define what quality of real-time you are trying to
accomplish and use examples from that realm and never claim that you can
deliver better service.  Multimedia real-time is different from
mission-critical real-timne.  Once the processor dynamically is
overcommitted, it is overcommitted and no real-time OS can help you.

David

===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598
URL: http://www.cacr.caltech.edu/~edelsohn/