Threads, Queue, Gemeinsame Daten

[folgemilch]

Hallo.

Mich bringt die nebenläufige Programmierung ein bisschen durcheinander.
Ich habe ein Programm, dass von einer Bluetoothschnittstelle Daten ausliest, daraus etwas berechnet und dann zeichnet. Da wäre nebenläufige Programmierung doch angebracht oder? Vorallem beim lesen des DataInputStreams von Bluetooth.
Das mit den Threads erzeugen und so geht ja noch ganz gut. Aber ich weiß nicht so recht wie ich das mit der Kommunikation zwischen den Threads machen soll. Kann ich eine Queue erzeugen, in die ich dann die Daten vom Stream hineinschreibe, mein berechnungs Thread schaut immer ob neue Daten in der Queue sind, wenn nicht macht er einen kleinen sleep, schaut dann wieder...
Wenn dieser Thread daten berechent hat möchte ich paintComponent in einem anderen Thread mit den eben berechneten Daten aufrufen.
Kennt jemand ein ähnliches Beispiel dass ich mir mal anschauen könnte, oder ne Seite die ich mal lesen sollte?

 

[Gelöschtes Mitglied 6946]

Du könntest dir mal BlockingQueue in der Java API-Doc anschauen. Der Konsument holt ein Element heraus und solang keines drin ist, blockiert der Aufruf, ein eigenes Sleep ist damit nicht mehr nötig. Diese spezielle Queue muss dann auch dem Produzenten bekannt sein, der dort dann neue Daten reinschreibt. Also wenn du mit Queues arbeiten willst, wäre das wohl ein brauchbarer Ansatz.

 

[Murray]

Ich habe ein Programm, dass von einer Bluetoothschnittstelle Daten ausliest, daraus etwas berechnet und dann zeichnet. Da wäre nebenläufige Programmierung doch angebracht oder?

Aus dieser Beschreibung ist für mich nicht ersichtlich, dass hier nebenläufige Programmierung gefragt ist - hier gibt es doch einen ganz klaren, seriellen Ablauf: erst einlesen, dann rechnen, dann zeichnen. Wo siehst du hier Raum für Multithreading?

 

[folgemilch]

Danke für die Antworten.
Die API der BlockingQueue hab ich mir angeschaut. Die kann ich glaube gut benutzen. Danke.

Brauche ich gar kein Multithreading? Wenn ich aus dem InputStream der Bluetoothschnittstelle mit read() lese, dann findet das doch blockierend statt oder? Das heißt wenn nur alle 50 ms Daten kommen, dann ist mein Programm solange blockiert wenn ich kein Multithreading verwende oder?

 

[Murray]

Wenn ich aus dem InputStream der Bluetoothschnittstelle mit read() lese, dann findet das doch blockierend statt oder? Das heißt wenn nur alle 50 ms Daten kommen, dann ist mein Programm solange blockiert wenn ich kein Multithreading verwende oder?

Richtig. Aber die Frage ist doch: was will dein Programm machen, solange keine weiteren Daten kommen? Gibt es währenddessen etwas zu tun? Falls das der Fall ist, dann lohnt es sich über Multhreading nachzudenken.

 

[folgemilch]

Gute Frage, was mache ich eigentlich wenn ich gereade keine Daten bekomme?
Wenn ich mein bisher gezeichnetes auf der ScrollPane verschieben will, wärend ich auf neue Daten warte, geht das dann? Oder hängt da wirklich das ganze Programm? So stell ich es mir vor.
Oder vielleicht geht meine Berechnung und das Zeichenen länger als 50 ms, dann verpasse ich doch den nächsten Wert im InputStream.
Also so sicher bin ich mir auch nicht, da ich sowas noch nicht gemacht habe. Aber ich glaube Multithreading wäre schon besser. Außerdem lerne ich dann was neues.

 

[skelle]

ich glaube "verpassen" tust du nichts... wenn Daten kommen du aber noch 50ms rechnest und erst dann anfängst zu lesen sollten die Daten immernoch im Buffer vorliegen... ist bei Netzwerkstreams ja das gleiche