invokeLater() vs synchronized(Object)

[-frank]

folgendes möchte ich für mein programm sicherstellen:
1. nicht mehrere useraktionen gleichzeitig.
2. keine aktionen während gui-aktualisierung.
3. keine aktualisierung während einer aktion.

derzeit synchronisiere ich mit einem simplen objekt, auf das eben synchronized zugegriffen wird. das bedeutet, dass zb ein mouseClicked(..) synchronisierten zugriff auf das objekt benötigt und nicht parallel zu einem actionPerformed(..) abgearbeitet werden kann.
ich frage mich jetzt, wie ich es mit der model/gui-aktualisierung halte. am einfachsten erscheint es mir, wenn man schon VOR der modelaktualisierung ebenfalls zugriff auf das zentrale synchobjekt benötigt. andererseits erscheint es mir sehr falsch, dass der view einfluss darauf hat, wann das model (von außen) aktualisiert werden darf.
folglich sollte ich die synchronisation wohl erst in den update-methoden der GUI machen oder? hätte es hier nun Vorteile, dies mit SwingUtilities.invokeLater() bzw. invokeAndWait() zu lösen?

natürlich kann es dann sein, dass sich die Daten im Model parallel zur Ausführung einer vom User (über die GUI) ausgelösten Aktion verändern (das Model kann in meinem Fall wie gesagt von anderer Stelle aus auch modifiziert werden): zb könnte ein GUI-Objekt, mit dem der User etwas tun möchte, im Model bereits entfernt worden sein (in der GUI aber eben noch nicht). Ist es üblich, dass man die Fehlerbehandlung dafür in den Controller packt? (und dann in der GUI ggf. Fehlermeldungen anzeigen lässt?)

 

[Wildcard]

Simultane GUI Aktionen sind technisch gar nicht möglich, eine Synchronisation daher unnötig.
Alle Events werden in eine Queue gepackt und sequentiell abgearbeitet.
invokeLater brauchst du genau dann wenn ein anderer Thread als der AWT Event Dispatcher Thread direkt oder indirekt die GUI beinflusst. Dieser Teil des Codes muss dann mit invokeLater in die Queue geschoben werden um vom Dispatcher Thread abgearbeitet zu werden.

 

[Guest]

invokeLater brauchst du genau dann wenn ein anderer Thread als der AWT Event Dispatcher Thread direkt oder indirekt die GUI beinflusst.

eine indirekte GUI beeinflussung habe ich durch eine Veränderung der Daten im Modell. angenommen im Model steht, dass es einen Kreis gibt mit 100pixel radius und farbe blau. dann wird das model von außen geändert und die farbe des kreises dadurch auf rot gesetzt. das model informiert alle listener --> listener.stateChanged().

in stateChanged() gibts dann entweder etwas in der Richtung jTextField.setText(model.getXY()) oder auch nur ein repaint().

wo bräuchte ich nun das invokeLater()? in der stateChanged()-Methode?
ist es auch bei einem repaint() notwendig? (das schreibt doch den repaint bzw. update-befehl auch nur in den awtthread oder?)

 

[Wildcard]

wo bräuchte ich nun das invokeLater()? in der stateChanged()-Methode?

Die Änderung des Models sollte über invokeLater erfolgen.

ist es auch bei einem repaint() notwendig? (das schreibt doch den repaint bzw. update-befehl auch nur in den awtthread oder?)

repaint muss nicht synchronisiert werden.

 

[-frank]

wo bräuchte ich nun das invokeLater()? in der stateChanged()-Methode?

Die Änderung des Models sollte über invokeLater erfolgen.

das verstehe ich nicht. sollte/muss das model ein objekt sein, das sich zwar auf mehrere gui-objekte (views) aber nur auf eine GUI, also einen AWT-Thread und vor allem auch nur auf das UserInterface bezieht?
ich hatte es mir nämlich so vorgestellt, dass dasselbe Objekte, das XYModel (für meinen XYView) implementiert, zb auch Daten für ein ganz anderes Nicht-GUI Objekt liefern könnte (die Daten wären ja dieselben, eventuell bräuchte ich nur andere Methoden oder vielleicht nicht mal das). Zb könnte eine andere Klasse die Daten prüfen und bei bestimmten Zuständen eine aktion auslösen. eventuell könnte es auch ganz andere programme geben, die zb über sockets mit dem model kommunizieren.
das model wäre dann ne art server, der view nur ein client (von vielen). und aus dieser sicht scheints mir total verkehrt, wenn ein (blockierender) client ein update des servers verhindert.
--> sollte man das Model wirklich nur für Views nurtzen? (also sollte ich nicht einfach eine Klasse, die zb ne Art Datenbank für viele andere Objekte/Programme darstellt), direkt XYModel implementieren lassen?)

(ich glaub ich muss nochmal im Netz stöbern, um mich besser in diesen Thema einlesen zu können)

 

[Wildcard]

das verstehe ich nicht. sollte/muss das model ein objekt sein, das sich zwar auf mehrere gui-objekte (views) aber nur auf eine GUI, also einen AWT-Thread und vor allem auch nur auf das UserInterface bezieht?

Es gibt nur einen einzigen AWT-Thread, jede GUI läuft in dem gleichen.

Das Model über invokeLater zu ändern ist die einfachste, aber nicht die einzige Möglichkeit.
Du musst folgende Bereiche abdecken:
-Thread x ändert das Model -> View wird über Listener aktualisiert -> Aktualisierung der View muss im Dispatcher Thread erfolgen

-Thread x ändert das Model während die GUI gerade Werte aus dem Model abfragt (aus eigener Initiative heraus) -> auch hier muss synchronisiert werden.