@noneuclideandreamer Ist mir nicht klar ob dadurch die Inkonsistenz vermieden werden kann. Aber versuch es Mal. Doch meist helfen sleep Aufrufe oder andere Verzögerung nicht zuverlässig.

Nachdem Java mit seinen Thread und seinem synchronized Schlüsselwort Ende der 90er verfügbar wurde kam aus der Praxis die Erkenntnis, dass es so nicht stabil wird und auch nicht auf viele Cores skaliert.

Sie habe dann ein komplett neues concurrent Paket entwickelt.

@noneuclideandreamer Eigentlich müsste das Datenmodell und die Logik in einem einzigen separaten Thread laufen. Der Zugang von außen müsste Thread Save eingepackt sein. Dem MirrorPanel.paintComponent würde eine konsistente Kopie des Datenmodells überlassen werden. Während die Logik den neuen auf neuen Variablen den nächsten Zustand berechnet.

@noneuclideandreamer In Erlang wäre die Variable state für niemanden sichtbar. Sie kann nur über eine thread save Warteschlange gelesen und verändert werden. Jede Message in der Warteschlange wird vollständig ausgeführt bevor die nächste dran kommt. Damit haben die ihre 99.999% Verfügbarkeit im Dauerbetrieb hinbekommen.

In Lisp (und heute ein Clojure) können Variable ihren Wert nicht ändern. Außer Atomic Variable. Lieber den alten Zustand wegwerfen als mit einem inkonsistenten Zustand arbeiten.

@noneuclideandreamer Heute Abend halte ich einen Vortag im Imkerverein. Muss jetzt los.