Thread-Problem, und synchronized bringt nix

[Rock Lobster]

Servus,

kann mir jemand in 2 - 3 Sätzen erklären, was genau das synchronized-Statement eigentlich bewirken soll? Meine bisherige Auffassung war eigentlich immer, daß Code, der sich in einem synchronized-Block befindet, von keinem anderen Thread unterbrochen werden kann und somit am Stück ausgeführt wird, also so, als gäbe es in diesem Moment keine anderen Threads.

Das Problem ist allerdings, daß ich noch nie das Gefühl hatte, daß mir ein synchronized-Block was bringt, denn immer wenn ich einen einsetzen will, um einen Thread-Fehler zu vermeiden, ist die Wirkung gleich null.

Mein konkretes Problem sieht zur Zeit so aus:
- eine Klasse besitzt einen Thread, der hin und wieder über eine Liste von Listenern iteriert, um diese zu benachrichtigen.
- die Klasse besitzt auch eine addListener()-Funktion, die einen Listener in die Liste einträgt.
- je nachdem wie der Mond grad steht passiert beides gleichzeitig, und das ist dann natürlich problematisch, da die Iteration es nicht gerne sieht, wenn da einer einen neuen Listener reinwirft.

Jetzt war meine Idee, die Iterationen einfach in einen synchronized-Block zu setzen, aber das bringt wie gesagt überhaupt nix. Möglicherweise ist eben mein Verständnis von synchronized irgendwie falsch, oder meine Java VM will sich nicht so recht dran halten

Also - wofür ist synchronized gut, und wie kann ich das Problem am elegantesten lösen?
Meine Idee wäre nun eine temporäre Liste als Zwischenlager zu erstellen, aus der sich der Thread immer dann, wenn er grad nicht mehr am iterieren ist, die neuen Objekte holt und in die eigentliche Hauptliste einfügt. Aber vielleicht geht das ja auch schöner?

 

[SlaterB]

synchronized bewirkt NICHT, dass, solange ein Thread ein Stück Code abgearbeitet, alle anderen Threads gestoppt werden,

synchronized bewirkt, dass, solange ein Thread ein Stück Code abgearbeitet, kein anderer Thread den gleichen Code-Block betreten darf

dieses Verbot gilt auch für alle anderen synchronized-Blöcke auf den gleichen Monitor

--------
wenn du also nur die Iteration synchronizierst, bewirkt das höchstens, dass niemand anders auch iterieren darf,
da das eh kein anderer macht, ist das recht nutzlos,

du musst auch das Einfügen auf synchronized setzen, und zwar mit dem gleichen Monitor,
dann ist der gegenseitige Ausschluss erreicht

class A {
  private List l;
  
  public synchronized void addSometingToList() {
  }

  public synchronized void doSometingWithList() {
  }


}

granatensicher


------

schlecht/ unsinnig wäre übrigens

public synchronized List getList() {
}

also die Liste synchronisiert abzufragen, dann aber in unsicherem Code zu durchlaufen

 

[Rock Lobster]

Okay, das funktioniert, vielen Dank.
Endlich hat es mal "Klick" gemacht

In Deinem Beispiel setzt Du ja die gesamte Methode auf synchronized - was wird dann als Monitor hergenommen? Und ist es prinzipiell immer richtig, z.B. das betroffene Objekt (in meinem Fall die Liste) als Monitor anzugeben? Oder gibt es da auch andere Möglichkeiten?

 

[hupfdule]

In Deinem Beispiel setzt Du ja die gesamte Methode auf synchronized - was wird dann als Monitor hergenommen?

Das Objekt, in dem sich die Methode befindet. In diesem Beispiel A.

Und ist es prinzipiell immer richtig, z.B. das betroffene Objekt (in meinem Fall die Liste) als Monitor anzugeben?

Ja, das wäre korrekt.

 

[SlaterB]

das A-Objekt wird in diesem Fall gewählt,

was sinnvoll ist hängt von der Situation ab, in deinem Beispiel scheint mir list sehr sinnvoll,
dann wäre es z.B. möglich, noch andere Teilbereiche (list2, list3) unabhängig von der ersten list zu synchronisieren,

Synchronisation auf das A-Objekt ist dagegen praktisch, wenn man viele Exemplarvariablen gleichzeitig bearbeitet
(wobei man sich auch auf einen bestimmten Monitor von diesen Variablen einigen könnte),
die elegante Syntax ist auch nicht zu verachten