[Vienna-pm] anmerkungen ..

[Bernd Petrovitsch]

On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote:
> Am Montag, 28. Mai 2007 schrieb Peter J. Holzer:
[...]
> > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du
> > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux,
> > Windows, ...) als auch um Perl einen großen Bogen machen. 
> Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus dem 

Weil es keine Garantien über Rechtzeitigkeit gibt, d.h. Garantien daß
bestimmte Funktionen/Subsysteme/... maximale Ausführungszeiten haben.

> Netz) aus Deutschland ist Perl (auch Python und so) viel schneller 
> programierbar als zB C oder C++ ist aber parktisch genauso schnell in 
> der Ausführung wie C (später kann man ja dann noch C erzeugen, wenn man 
> möchte). In C muss man aber jeden Kleinkram selber machen und C++ und 
> Java sind etwas für Romaschreiber - nix für Faule ;)

Das hat alles mit "Echtzeitfähigkeit" nach akademischer Definition (und
damit der wahren) nichts zu tun.
Das Problem, daß die Welt mit dem Begriff "Echtzeit" hat ist, daß er in
den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten als
Marketing/Sales-Buzzword für "sofort", "möglichst schnell",
"unverzüglich", u.ä. technisch wenig sinnvolle Adjektive vergewaltigt
wurde.

Tatsächlich bedeutet Echtzeitfähigkeit, daß eine gegebene
Aufgabe/Algorithmus/Problem nicht nur Ergebnis-mäßig korrekt gelöst
wird, sondern auch zusätzlich noch Zeitvorgaben einhält. Und es ist
völlig irrelevant, welche Dimension die Zeitangabe hat. Z.B. könnte eine
Bank definieren, daß sie am 4. Jänner 00:00 Uhr die Jahresabrechnung des
letzten Jahres fertig haben will. Voila, wir haben einen festen Termin
in der Spezifikation und damit ein Echtzeitsystem.

Und dann unterscheidet man noch zwischen "soft realtime" und "hard
realtime":
soft: Wenn man die Zeitvorgaben nicht einhält, dann ist der Verlust im
      wesentlichen der entgangene Nutzen.
      Z.B. gibt es für den Verbindungsaufbau im ISDN eine maximale Dauer
      (20µs oder so). Wenn das bei einem normalen Telefonanruf mal
      länger dauert, wird nicht viel passieren ....
hard: Der Schaden ist signifikant größer.
      Typische Bsp. sind Flugzeug- und/oder Eisenbahnsteuerungen,
      diverse Maschinensteuerungen. Wenn da was zu langsam
      geregelt/gesteuert wird, dann kracht es idR ordentlich.

[...]
> bearbeiten und jeder Ansatz sollte selbständig sein. Mir ist lieber 
> mehrere kleine Programme die definierte kleine Aufgaben erledigen, als 
> ein Riesending für alles.

Tja, der Hund bei Echtzeitsystemen als solchen ist, daß Du nur das
gesamte System dann und nur dann echtzeitfähig bekommst, wenn Du ganz
unten damit anfängst.
Wenn nicht, dann muß du mit dem Restrisiko leben. Das mag größer oder
kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es
mit Hardware nicht erschlagen können.

Für mehr kann man z.B. http://ti.tuwien.ac.at/rts/teaching/courses/ezs
besuchen ......

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services