awt und multithreading

net 0

hi,
kann man methoden für ein und dasselbe component-objekt (z.b. setBackground()) aus mehreren threads aufrufen ohne race conditions, abstürze etc.?
oder muss man sich dann wrapper-funktionen basteln mit 'synchronized' davor?

2te frage:
kann man, von einem anderen thread aus, events simulieren und diese in die queue einspeisen, so dass der entsprechende listener die events ausführen kann, allerdings im context des 'normalen' threads?

bin für jede antwort dankbar

interpreter

net schrieb:

bin für jede antwort dankbar

Gut. Dann antworte ich auch mal auf die Gefahr hin, Mist zu erzählen

So weit ich weiß ist es problematisch, mit mehreren Threads auf die GUI zuzugreifen. Abstrürzen wird das Programm nicht, aber es könnte ein seltsames Verhalten an den Tag legen. Ich würde versuchen, so viel zu synchronisieren wie es geht oder alle Befehle in eine Queue packen.

Zur 2. Frage:
Schau dir mal SwingUtilities.InvokeLater() an.

Noch ein paar Infos findest du hier:
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)

net 0

interpreter schrieb:

Zur 2. Frage:
Schau dir mal SwingUtilities.InvokeLater() an.

ja, danke, das und 'InvokeAndWait' habe ich auch gerade gefunden. damit kann man events in die event queue einschleusen. thread safe

btw: wen's interessiert. es gibt auch ein buch darüber (ebook)
- java threads
von scott oaks und henry wong
o'reilly, 1999

Ich fang auch grad mit Swing an. Kurze Frage:

class WindowThread implements Runnable
{
	public void run()
	{
		JFrame frame = new JFrame("Blubber-Fenster");
		frame.setSize(400, 300);
		frame.setResizable(false);
		frame.setLocation(300, 230);
		frame.setDefaultLookAndFeelDecorated(false);
		frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		frame.setVisible(true);
	}
}

Wenn ich diesen Thread starte, dann läuft der "normale" Thread natürlich weiter, bis er zu einem Ende kommt. Aber dieser Thread hier müsste doch auch recht schnell zu einem Ende kommen?
Warum wird das Programm trotzdem nicht beendet?

interpreter

Jeder Frame startet beim Anzeigen (durch setVisible(true) oder show()) seinen eigenen Thread für die Events. Der Thread für deinen JFrame läuft so lange, bis du das Fenster schließt und da das ja kein Demon-Thread ist läuft solange auch dein Programm weiter.

Also das setVisible startet eine Messageloop? Geil, dass das in der Doku steht.

Das macht jetzt aber nur dieses JFrame, oder machen des die ganzen Buttons und so auch?

interpreter

Optimizer schrieb:

Also das setVisible startet eine Messageloop?

Ja

Das macht jetzt aber nur dieses JFrame, oder machen des die ganzen Buttons und so auch?

setVisible ist eine Methode von JComponent, also machen das wohl alle Subklassen von JComponent so. Warum sollte man auch ein Eventhandling für eine Komponente starten, wenn sie nicht sichtbar ist?

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht. Komisches System. Das Tutorial von Sun suckt auch irgendwie.

net 0

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht.

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Ne, sieht nicht so aus. Wenn ich das Fenster nicht sichtbar mach, wird das Programm sofort wieder beendet.
Das mit dem dispose() scheint zu stimmen.

interpreter

net schrieb:

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht.

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Nein.

Ok, also ist das jetzt so korrekt, dass der Event Thread startet, sobald das erste Control sichtbar ist und endet, sobald das letzte Control disposed ist?

Wieso steht das nicht in der Doku oder im Sun-Tutorial? Ich finde das nicht unwichtig, zu wissen, was für Threads wie lange laufen.

interpreter

Ich habe mich nie sooo genau damit beschäftigt, wann nun wo irgendwelche Threads starten (braucht man eigentlich auch nicht). Wenn erforderlich, dann startet eben der AWT Thread und anscheinend gibt es immer nur einen Thread für alle Events:

Swing event-handling and painting code executes in a single thread, called the event-dispatching thread

http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
(Dies allerdings nur die logische Betrachtung. Effektiv kann der AWT-Event-Thread aus mehreren Threads bestehen).
Mit SwingUtilities kann man selber Aktionen in diese Event-Queue einreihen.

Wann dieser Thread genau endet kann ich dir nicht sagen. Vermutlich wenn er eben nicht mehr benötigt wird und das wäre dann, wenn keine Komponente mehr sichtbar ist.

net 0

interpreter schrieb:

net schrieb:

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang....

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Nein.

wie nein?
das mit dem 'dispose' oder das mit dem starten des threads?
mein aussage bezog sich übrigens auf normales awt, also ohne swing

interpreter schrieb:

Mit SwingUtilities kann man selber Aktionen in diese Event-Queue einreihen.

...und mit java.awt.EventQueue