realtime design

Tim Daneliuk tundra at tundraware.com
Tue Oct 15 05:46:33 CEST 2002


Will Stuyvesant wrote:
> We would like to prototype a realtime system.  Is anybody doing this using Python?
> 
> '''
> A lost ounce of gold may be found, a lost moment of time never.
> '''

Much has already been posted here but I would add this:

There is an inherent problem with the term "realtime" if it is not
further qualified.  All realtime systems must typically cope with external
asynchronous events as their principal paradigm - i.e., Asynchronous
events determine control flow of the code not some master algorithm.
However, all such systems are not equal.  Generally, we can think about
two classes of realtime systems:

1) "Hard" realtime - cases where timing must be predictable and guaranteed.
     For example, "You must respond to the Flabergast Interrupt in less than
     100 us and guarantee it is serviced completely in 1ms."  This kind of
     thing is common in machine control and military fire control systems.

2) "Soft" realtime - cases where you must respond to external events in
     a reasonable amount of time and preserve proper *sequencing*, but the
     absolute amount of time is neither guranteed nor particularly important
     unless it gets ridiculously long.  A good example of this is the
     message processing and dispatching common in a GUI manager.

I would argue that Python is possibly suited to 2) and probably poorly suited
to 1). The reason I say this is that things like background garbage
collection, interaction with lower-level system services like I/O and so on
make guaranteed, predictable service times essentially impossible (unless
the guarantees are so weak and the permissible times so long that it does
not matter - but this is not ordinarily the case in hard realtime).

It might be possible to shoehorn Python into a hard realtime environment
for some functions like dispatching if one wrote a sufficient amount of
binder code in a lower level language like 'C' or Assembler, but why
bother?  Python is a marvelous language with many merits, but it cannot do
everything - no language can, nor should it be expected to. - Shameless
promotion of my ideas on *that* subject can be found at:

                   http://www.tundraware.com/Technology/Bullet/

If you shudder at writing in Assembler or 'C', give Forth a good look
for this sort of thing.

My view is that higher abstraction langauges, especially those involving a lot
of dynamic runtime behavior are poor fits for hard realtime and even (often)
very challenging for soft realtime.


HOWEVER, you said you wanted to "prototype" such a system.  Depending on how
functional your prototype needs to be, Python may well be a good choice.
It is relatively easy and quite appropriate to *model* realtime systems, hard
and soft, in other languages.  I once wrote a operating system VM simulation
in 'C' which had nothing to do with a real OS, but was an exercise designed
to examine paging behavior and get some sense of how different swapping algorithms
handled different page working sets.  It was a useful and interesting
project which is sorta-kinda-somewhat realtime-ish.

Just my 2 bits worth ...





-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com




More information about the Python-list mailing list