www.mikrocontroller.net

Forum: PC-Programmierung Echtzeit mit JAVA


Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Betriebssys...

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rayk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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....

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-...
(ist eine Dissertation von 2001)
http://www.fridi.de/rts/papers/

Die dazugehörige VM nennt sich JamaicaVM.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jürgen G. (jg32)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Jürgen G. (jg32)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rayk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rayk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: abcdef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!)
> im RAM an
Welch ein Kassensystem hat 12GB RAM?

Autor: Jürgen G. (jg32)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: abcdef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Rayk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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... ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.