Hallo, lese in letzter Zeit des öfteren von harten Echtzeitanwendungen auf JAVA Basis (IBM developer site). Hierzu eine Verständnisfrage: JAVA setzt auf einem Standard Linux Betriebssystem auf und implementiert die RT Funktionen. Wo liegt der technische Vorteil dieser Technologie gegenüber einem Echtzeitbetriebssystem a la RTLinux / RTAI mit Kernelerweiterung? Danke & Gruß Chris
Ein Vorteil von JAVA soll eigentlich sein, daß es plattformübergreifend laufen kann, ein Nachteil ist, daß es meist viel Speicher frisst und oft langsamer ist. Von Lizenzproblemen wie SUN+MS abgesehen wäre es gut, ein Echtzeitsystem zu haben was dann überall läuft. Es bleibt jedoch die kleine Frage bei mir, ob das jeweilige Betriebssystem überhaupt Lust hat, JAVA das entsprechende ZEITFENSTER bedarfsgerecht zur Verfügung zu stellen. Sobald dann wegen Echtzeit größere Eingriffe ins jeweilige BS nötig sind, tauchen dann bei mir weitere Fragen zur Sicherheit auf. Deshalb hat wohl bisher jeder sein Süppchen gekocht. http://de.wikipedia.org/wiki/Liste_der_Betriebssysteme#Eingebettete_und_Echtzeit-Betriebssysteme
Mit Java können keine harten Echtzeitanforderungen gewährleistet werden, da es einen Garbage Collector zum Aufräumen des Speichers verwendet und der ist mit den Anforderungen eines harten Echtzeitsystems nicht in Einklang zu bekommen...
>Mit Java können keine harten Echtzeitanforderungen gewährleistet werden, >da es einen Garbage Collector zum Aufräumen des Speichers verwendet Ich bin mir nicht sicher, ob man das so pauschal sagen kann. Der Garbage Collector läuft ja in der Regel niederprior. Wenn das System genug Reserven hat, sollte es damit doch zu keinem Speichermangel kommen!? Natürlich muss man entsprechend sorgfältig programmieren und optimieren; aber das ist ja immer so. Mehr als einen Speichermangel kann der GC doch nicht verursachen oder sehe ich da was falsch?
"Implementierungen der Kertasarie VM stehen in diesem Bereich sowohl für Geräte der PalmOS Klasse als auch für iPaq-PDAs von Compaq zur Verfügung. Sie eignet sich aber auch sehr gut für die Integration in Mobiltelefone oder schnurlose Telefone." Das nennt du harte Echtzeit. Ohne Worte....
Java laeuft in einer VM, die wiederum auf einem OS laeuft, das seinerseits bereits nicht echtzeitfaehig ist. Wie sollte man hier jemals harte Echtzeit realisieren koennen. Wo willst Du das denn bitte gelesen haben?
ich wrote: > Mit Java können keine harten Echtzeitanforderungen gewährleistet werden, > da es einen Garbage Collector zum Aufräumen des Speichers verwendet und > der ist mit den Anforderungen eines harten Echtzeitsystems nicht in > Einklang zu bekommen... Das ist seit längerem nicht mehr der Fall. http://www.amazon.de/Realtime-Collection-Oriented-Programming-Languages/dp/3831138931 (ist eine Dissertation von 2001) http://www.fridi.de/rts/papers/ Die dazugehörige VM nennt sich JamaicaVM.
Speicherorganisation / GC http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection ist eine Sache. Aber wer garantiert, das jedes darunterliegende Betriebssystem JAVA überhaupt ein Zeitfenster zur rechten ZEIT freigibt??
Java, RT OS und RT GC müssen natürlich zusammenpassen. Für Java soll es sowas geben, für .NET hätte ich das auch gerne. Aber Java für RT Aufgaben macht nur dann Sinn wenn man schon eine vorhandene Codebasis in Java hat oder die Programmiertruppe nur Java beherscht. Sonst ist Standard C/C++ sicher am weitesten verbreitet für RT Programmierung.
> Aber Java für RT Aufgaben macht nur dann Sinn wenn man schon eine > vorhandene Codebasis in Java hat oder die Programmiertruppe nur Java > beherscht. Sonst ist Standard C/C++ sicher am weitesten verbreitet für > RT Programmierung. Das ist der Punkt: Die meisten Java-Programmierer können von Natur gut Web- und Geschäftsanwendungen entwickeln, haben aber mit RT-Program- mierung nicht viel Erfahrung. Richtig RT programmieren zu lernen dauert deutlich länger als von Java auf C umzusteigen. Java auf Echtzeit aufzupimpen hat also nur einen beschränkten Nutzen. Und wenn man für Benutzerschnittstelle, Netzwerkanbindung u.ä. Java bevorzugt, kann man die echtzeitkritischen Teile ja trotzdem in C oder C++ implementieren.
Ich habe vor 2 Jahren ein PC Windows programm geschrieben, was sich mit einem angeschlossenen Embedded System ueber RS232 unterhaelt. Angefangen habe ich mit C++ und habe die normalen Windows API Funktionen benutzt zur RS232 Kommunikation. Ergebnis: unbrauchbar. Um ein Byte rauszuschicken und wieder empfangsbereit zu sein, sind 10ms vergangen, d.h. ein Handshake 20ms. Ich haette natuerlich an Windows-Scheduling-Parameter rumschrauben koennen, aber so tief wollte ich nicht in das System einsteigen. So nahm ich Java. Das ging bedeutend (5x !) schneller. (ohne irgendwelchen Einstellungen) Das war eine Anwendung, die binnen weniger Millisekunden Daten vom RS232 empfangen, verarbeiten und wieder abschicken musste.
@Jürgen G. Das ist schwer zu glauben, denn Java nutzt auch bloss die WindowsApi dann anders kommt man an die schnittstelle nicht ran. Und wie eine zusätzliche Software die geschwindigkeit erhöhen soll ist mir nicht klar. Ich vermute mal der Fehler lag in dem C Programm.
Peter wrote: > @Jürgen G. > dann anders kommt man an die schnittstelle nicht ran. Und wie eine > zusätzliche Software die geschwindigkeit erhöhen soll ist mir nicht > klar. Einfach, indem man in den Scheduler von Windows eingreift. Ich weiss, wie man das bei Linux macht, bin aber kein Windows-Experte. Ich wollte nur eine Standard-App schreiben. Die benutzten Funktionen waren auf den Code - Fragmenten von www.msdn.com aufgebaut.
Jürgen G. wrote:
>So nahm ich Java. Das ging bedeutend (5x !) schneller.
Java nutzt ja bekanntlich eine VM, um den plattformunabhänigen Bytecode
in den zielgerät-spezifischen Binärcode umzusetzen. Die VM setzt dabei
immer auf den API's des jeweiligen Zielsystems auf. D.h.: Java nutzt
auch nur die Windows-API. Durch Just-In-Time-Compiler kann Java sehr
schnell werden; in etwa so schnell wie gut optimierte C/C++-Programme.
Wenn Deine Java-Applikation allerdings 5x schneller als Dein C-Programm
war, war Dein C-Programm miserabel optimiert (Optimierung des
C-Compilers ausgeschaltet ???).
Gruß,
Rayk
oops, da waren wieder zwei schneller...
>Einfach, indem man in den Scheduler von Windows eingreift.
Jürgen, das relativiert Deine Aussage wieder...
(Wenn die VM das kann, dann kann das Dein C-Programm auch ;o) , und
damit hätte das C-Programm bestimmt die Nase vorn gehabt...)
Nur mal zum Thema GarbageCollector: Kassenanwendung einer großen Bank, Testweise mal in Java. Nach ein Paar Tagen meldeten einige Filialen, dass das Programm sich aufgehängt hatte. Nach Intensiven Tests stellte sich heraus das es der Garbagecollector schuld war: Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!) im RAM an, bis der GC mal loslegte. Das die PC´s in den Filialen das nicht bewältigen konnten ist natürlich klar. Nach etlichen Stunden lief das Programm dort natürlich weiter als wäre nichts gewesen...
> Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!) > im RAM an Welch ein Kassensystem hat 12GB RAM?
>Wenn Deine Java-Applikation allerdings 5x schneller als Dein C-Programm >war, war Dein C-Programm miserabel optimiert (Optimierung des >C-Compilers ausgeschaltet ???). Das Problem lag m.E. an der Tatsache, dass meine Callback-Routine (welche empfangene Daten verarbeitet) nicht unmittelbar nach dem Dateneingang aufgerufen wurde, sondern erhebliche Zeit spaeter, vermutlich zu der Zeit wo Windows sowieso die Tasks geswitcht haette. Daran konnte ich in meinem Code gar nichts aendern. Ich benutzte den Compiler mingw-gcc. An den Optimierungen hatte ich ein bisschen rumgespielt, aber half nichts.
> Das Problem lag m.E. an der Tatsache, dass meine Callback-Routine > (welche empfangene Daten verarbeitet) nicht unmittelbar nach dem > Dateneingang aufgerufen wurde, sondern erhebliche Zeit spaeter, So etwas macht nicht mal Windows. Wenn du wartest bis Daten vorhanden sind und dann das Zeichen abrufst danach deine Callback aurufst, dann ist die Zeitscheibe von deinem Thread gerantiert nicht abgelaufen. Das ganze sollte weniger als 1ms dauern. Der Scheduler entzieht dir bloss deine Rechenzeit wenn du sie bis zum ende ausreizt. Wenn aber Daten ohne grosse berechnung von der Seriellen Empfangen werden dann langweilt sich der Rechner. Und Sobald dein Thread auf das nächste Zeichen wartet, gibt du selber die Rechenzeit ab. Damit ist es völlig egal auf welches Timing im scheduler eingestellt ist.
wenn der GC das problem ist, ruf' das teil einfach explizit auf, dann gibt's nicht so viel datenmüll. zum C programm, hast du das terminal auch richtig konfiguriert, alle buffer aus und so weiter?
abcdef wrote: > Nach Intensiven Tests stellte sich heraus das es der Garbagecollector > schuld war: > > Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!) > im RAM an, bis der GC mal loslegte. Das die PC´s in den Filialen das > nicht bewältigen konnten ist natürlich klar. Auch ein GC kann nicht zaubern. Viele Java-Programmierer scheinen zu meinen, mit einem GC braucht man sich um nichts mehr zu kümmern und kann ohne Sinn und Verstand Speicher verschwenden, der GC wird's schon richten. Das klappt nicht.
>Welch ein Kassensystem hat 12GB RAM? Schonmal was von Virtuellem Arbeitsspeicher gehört? Ziemlich langsam, aber funktioniert... Die 12GB wurden auf einem der Entwicklungsrechner gemessen, die haben etwas mehr RAM :-) >Auch ein GC kann nicht zaubern. Viele Java-Programmierer scheinen zu >meinen, mit einem GC braucht man sich um nichts mehr zu kümmern und kann >ohne Sinn und Verstand Speicher verschwenden, der GC wird's schon >richten. Das klappt nicht. Der GC wurde zwischendurch immer wieder extra aufgerufen. In einem Testprogramm zum GC stellte sich aber heraus, das der GC nicht unbedingt auf das Programm hört. Er wurde korrekt aufgerufen und machte meistens alles richtig, manchmal aber auch einfach NICHTS...
>Er wurde korrekt aufgerufen und machte meistens alles richtig, >manchmal aber auch einfach NICHTS... Tja, dem GC wird manchmal auch etwas zuviel zugemutet. Der GC muss ja im Prinzip jedes angelegt Objekt prüfen, ob noch Referenzen darauf existieren. Sind noch Referenzen vorhanden müssen diese geprüft werden. Existieren "rekursive" Referenzen, kann so mancher GC den Objekt-Klops nicht entsorgen. Java-Programmierer vergessen manchmal, dass man dem GC etwas unter die Arme greifen sollte: nicht mehr benötigte Referenzen werden auf 'null' gesetzt. Und schon hat der GC viel weniger tun! Es ist also kein Problem des GC sondern einer schlampigen Programmierung! >Auch ein GC kann nicht zaubern. Viele Java-Programmierer scheinen zu >meinen, mit einem GC braucht man sich um nichts mehr zu kümmern und kann >ohne Sinn und Verstand Speicher verschwenden, der GC wird's schon >richten. Das klappt nicht. Genau das ist das Problem!
>> Welch ein Kassensystem hat 12GB RAM? > Schonmal was von Virtuellem Arbeitsspeicher gehört? Ziemlich langsam, > aber funktioniert... Nach dem Senden fiel mir das auch ein... ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.