Hallo,

In meinem aktuellen Projekt nutze ich Java in Verbindung mit OpenGL (JOGL).
Dort gibt es eine Klasse namens Animator, die einen Thread bereitstellt, der sich um das Updaten von OpenGL kümmert. In diesem Thread werde ich also sämtliche Darstellungen vornehmen.
Die Programmlogik hingegen, möchte ich in eine andere Klasse, bzw. am besten sogar in einen anderen Thread auslagern. Jetzt frage ich mich, wie ich diese beiden Threads am besten synchronisieren kann.
Die Idee war es, dem Render Thread eine Liste von Objekten zu geben, die dieser dann zeichnen soll.

Ich könnte nun zu jedem Objekt eine weitere Klasse hinzufügen, in der die Informationen für die Darstellung gespeichert sind. In einem Observer-Modell könnte nun die Logik-Klasse der Darstellungs-Klasse die Änderungen mitteilen. Die Methoden der Darstellungs-Klasse würden dann alle synchronized gemacht werden und der Renderer könnte problemlos auf diese zugreifen.
Da die Logik aber primär Auswirkungen auf die Darstellung hat, kann ichs auch in eine Klasse packen.

Ist das sinnvoll, oder gibt es eine bessere Methode?

Gruß,
Seth

Ahoi,

1. wisse, dass JOGL langsam ist. Ich würde eher lwjgl nehmen. Das ist performanter.

2. Im Wesentlichen musst du doch nur im Renderthread eine Queue von Runnables haben, in die du aus den anderen Threads was reinstopfst. Guck dich da mal im java.util.concurrent package um, das hat da sehr gute BoundedQueues und Executoren für Threads, womit das ziemlich einfach ist. Im Renderthread gehst du dann einfach Runnable für Runnable deine Queue durch und führst es aus. In den Runnables sind dann die Aufrufe an lwjgl drin (= aka: Dein Rendercode).

3. Sehr zu empfehlen ist das Buch "Concurrency in practice", wenn du was mit Concurrency in Java machen möchtest

4. Ich würde mich gar nicht so sehr darauf festlegen, dass das Datenmodell und die Darstellung so eng aneinander gekoppelt sind und dauernd über Observer voneinander erfahren. Das Observer-Pattern ist schon länger veraltet (aus gutem Grund) und wenn du exzessiv synchronisieren musst, geht die Performance auch eher Richtung Keller

5. Vergiss nicht: Multi-Threaded ist wesentlich schwerer als Single-Threaded. Ich würde da sehr genau abwägen, ob sich das lohnt.

Hope this helps
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

1. JOGL benutze ich primär, weil ich diverse Probleme mit der lwjgl hatte. Performance spielt keine Rolle, da es sich nur um eine 2D Anwendung mit geschätzten 30-40 Polygonen handelt. Nichts Großes

2. Klingt sehr interessant. Implementieren dann praktisch die Objekte, die ich zeichnen möchte das Interface Runnable, oder wie darf ich mir das vorstellen?

3. Schau ich mir mal an, danke

4. Ja das hab ich mir inzwischen auch gedacht und die Idee mit den Observern verworfen.

5. Nein lohnt sich nicht Momentan ist es halt wie folgt:

main Methode erzeugt Animator Objekt (da kommt Thread #1 her) und eine Game Klasse, die hat eine Endlos-Update Schleife in Thread #2und eine draw() Methode. Beide sind synchronized.
Um das ganze nun Single-Threaded zu machen, müsste ich ich auf das Animator Objekt verzichten oder davon erben. Ist das sinnvoll? Ich würde dann den klassischen Ansatz wählen:

Momentan laufen die halt parallel.

Wegen dem Runnable: Genau so macht es übrigens der EventDispatchThread von Swing. Man macht ja alle GUI-Operationen (in Swing) im EDT und dafür gibt's entsprechende Hilfsmethoden (wie z.B. invokeLater):


Und analog dazu könntest du dir halt ein RenderThread.invokeLater(...) machen. Das muss auch nicht zwingend Runnables nehmen, aber die bieten sich halt an

Könnte also so aussehen:


Alle Klarheiten beseitigt?
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Fast alle Klarheiten

Das ist jetzt schon fast Off Topic. Aber wie läuft das, wenn ich es in einem einzigen Thread machen will?

So siehts momentan aus:

In der Renderer Klasse (die GLEventListener implementiert) gibt es dann diese Methode:
die afaik in dem Animator Thread läuft. In dieser Methode möchte ich aber keine Logik-Berechnungen machen.
Ich könnte alternativ den Animator weglassen und display() selbst manuell aufrufen, aber das ist glaube ich nicht Sinn der Sache.

Öh... ich bin mir nicht ganz sicher, deine Frage zu 100% geschnallt zu haben,

aber angenommen, du willst das alles in einem Thread machen (z.B. alles im RenderThread) und du nutzt den Code von oben, dann klappt das natürlich nicht: Denn du schreibst damit etwas auf die "ToDo-Liste" des Threads, der diese Liste auch wieder abarbeiten muss. Und entweder macht der Thread die Abarbeitung von dem Zeug _oder_ das Hinzufügen von ToDo-Einträgen Wenn er abwechselnd was hinzufügt und dann direkt danach wieder abarbeitet, ist das ganze etwas witzlos.

Da du (z.B. beim EDT von Swing) auch auf die Abarbeitung eines solchen Runnables warten kannst (mit invokeAndWait statt invokeLater), ist es sogar wichtig, dass es zwei verschiedene Threads sind: Würdest du nämlich mit invokeAndWait auf die Abarbeitung im selben Thread warten, würdest du ewig warten (Das oft zitierte Deadlock): Du würdest nämlich auf dich selbst warten.

Deswegen prüft der EDT von Swing das beispielsweise und wirft eine IllegalStateException iirc. Und dafür gibt's beim EDT auch diese tolle Methode SwingUtilities.isEventDispatchThread() (oder so ähnlich).

~Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ja das war was ich meinte. Die eigentlich Frage war: Wie stelle ich am besten an, dass ich Logik und Rendering nun in einen Thread packen kann?

Zu Animator steht in der Doc folgendes:

D.h. ich könnte folgendes probieren:

Oder? Dann hatte die Gui zwar immer noch ihren eigenen Thread, aber das sollte ja nicht weiter schlimm sein.

Ich verwende jetzt ausschließlich einen Thread (bin inzwischen sogar wieder auf den Animator umgestiegen) und rufe meine update() sowie meine render() Methode beide in


auf. In meiner update() und render() Methode iteriere ich jeweils über eine Liste (die selbe) und bekomme wenn ich Listenelemente löschen möchte (meistens) eine ConcurrentModificationException.
Aber müssten die nicht, dadurch dass beide von display() aufgerufen werden, im selben Thread laufen? Wie kann es da zu so einer Exception kommen?

In update() passiert etwa so etwas:


Das Problem tritt sogar dann noch auf, wenn ich um den gesamten Block ein synchronized mache.

Wenn ichs so mache, scheint überhaupt nichts mehr zu passieren (weißes Bild):


hm ich lese grad, dass es normal ist, dass der fehler auftaucht, wenn man während des iterierens löschen, will aber mit nem iterator solls angeblich gehen ...

so gibts wieder die exception:

ok wenn man it.remove() nimmt, scheint es zu gehen

Jupp Die Iteratoren in Java sind zum Großteil fail-fast. Das ist exzessiv in der Javadoc dokumentiert. Besser kann ich's eigentlich auch nicht ausdrücken.

Das Verhalten hängt von der unterliegenden Implementierung ab. Die ArrayList z.B. ist nicht thread-safe (Dafür gibt's Vektor). Genaueres steht da in der Javadoc dazu. Ab dem fett markierten "not threadsafe"

Speziell das hier ist interessant für dich (und hat mit Threads übrigens absolut gar nichts zu tun):

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."