Daten ohne Blockierung des Hautprogramm verarbeiten

[Luma]

Hio.
Ich hab hier eine kleine Frage an euch. Und zwar schreibe ich gerade an einem Programm, das GPS-Daten (genau, das Global Positioning System) bekommt, verarbeitet und anschließend visualisiert. Ich habe dafür eine Klasse GPSSession die eben die aktuelle Session darstellt und in gewissen Zeitabständen (exakt eine Sekunde) neue GPS-Daten bekommt. Des Weiteren habe ich eine Klasse SurveyComponent, die die GPS Session visualisieren soll. SurveyComponent meldet sich bei GPSSession als GPSSessionChangeListener an. Aber nicht nur diese eine graphische Komponente tut das, sonder noch viele mehr, die jeweils komplexe Visualisierungen bieten.
Jetzt zur eigentlichen Frage: Jedes mal wenn GPSSession neue Daten bekommt werden alle Listener davon informiert (das geschieht über eine Schleife mit einem Iterator) und jeder Listener bekommt ein Objekt der Klasse GPSSessionData in der die aktuellen Eigenschaften der GPSSession (wie Position, Richtung, Bewegungsdauer, Geschwindigkeit et cetera) gespeichert sind. SurveyComponent zeichnet z.B. eine Art Karte. Wird es von GPSSession mit neuen Daten versorgt dann wird die Karte neu gezeichnet – und das dauert einen Moment. Wenn SurveyComponent neu zeichnet muss GPSSession ja solange warten, bis SurveyComponent fertig ist und kann dann erst den nächsten Listener updaten – und dadurch wird ja der Programmablauf geblockt. Das dürfte ein ziemlicher Flaschenhals in meinem Programm werden.
Jetzt hab ich mir überlegt wie man das umgehen könnte. Als nächste Lösung schien mir Multithreading, aber das ist auch so ne Sache. Ich hab mir überlegt wie ich das implementieren soll, und hab mir das dann so gedacht:
Listener wird aufgerufen --> neuer Thread wird erzeugt der die Daten verarbeitet --> Daten werden visualisiert. Dabei wird GPSSession ja nicht geblockt da der Thread ja „parallel“ zum Hauptprogramm weiter läuft. Was mach ich aber wenn Thread 1 noch nicht fertig ist und der Listener wird wieder geupdatet? Einen neuen Thread erstellen, der dann auf den alten wartet? Das ist auch nicht gerade die Lösung, irgendwan ist mein Programm mit dem Zeichnen so weit hinterher, so dass das gezeichnete mit der echten physikalischen Situation (ich hoff das sagt man so; ich mein damit einfach das hier und jetzt) nicht mehr übereinstimmt.

Hat vielleicht jemand eine smartere Lösung?


Gruß und Danke an alle die mir antworten
Lutz

 

[Leroy42]

Ich finde die Thread-Lösung schon sinnvoll.

Wenn dann ein Listener benachrichtigt wird, dessen vorhergehende Bearbeitung noch nicht beendet wurde,
gibt es mehrere Möglichkeiten zu reagieren.

1) Der aktuelle Aufruf wird ignoriert ==> aktuellere Daten gehen verloren.
2) Der aktuelle Aufruf wird in einer LIFO-Liste zwischengespeichert und später abgearbeitet.
==> Es kann passieren, daß mehr Aufträge eingehen als abgearbeitet werden.
3) Nur der neueste Aufruf wird zwischengespeichert.
4) Dem laufenden Abarbeitungsthread wird mitgeteilt, daß aktuellere Daten da sind und
er sich schleunigst beenden soll um diese neuen Daten zu verarbeiten.

Ich selbst würde zwischen Lösung 3 und 4 schwanken. Wobei 4 sicher nicht ganz so einfach
zu realisieren ist.

 

[Luma]

Hmm...
GUI-Programmierung ist immer das schlimmste. Der eigentliche Code ist ja schon ziemlich kompliziert und dann auch noch der Aufwand mit dem Visualisieren...

3) Nur der neueste Aufruf wird zwischengespeichert.

Das ist doch genau das gleich wie bei 1), oder nicht? Korrigier mich bitte, wenn ich was falsch verstanden habe.

Auf jeden Fall mal Danke für deine Antwort.
Ich probier als erstes die Queue (ich hoff das schreibt man so). Das Problem ist halt, dass auf langsameren Computern es wirklich dazu kommt, dass die Queue ständig wächst. Ich werd das testen.

Gibt's vielleicht noch ein paar andere Vorschläge? Bin für jeden Dankbar.

Gruß
Lutz

 

[Ilja]

dieser Flaschenhalst istimmer ein Problemm und eher eine Voraussetzung an das Verarbeitende System.
Die Software hat nicht umsonst eine Mindestvoraussetzung!

Du könntest noch folgendes Probieren:
ordne dem Zeichnungs-thread die höchste Priorität zu - die meißten Betriebssystemme unterstützen dies. So hättest du den hals etwas geweitet!

die Queue ist nur bedingt eine lösung, denn wenn das system die zeichnung im DURCHSCHNITT nicht < 1s fertigstellen kann, wird diese Queue immer größer und das Programm umso langsammer! Wenn du <1s im schnitt erwartest, so ist die queue die besste lösung!
Erweitere die Queue um eine Prüfung der anzahl der Elemente! Sobald diese >5 sind z.b., sollen alle bis auf das letzte Element gelöscht werden - somit kannste einen induktiven Stau überspringen!