Java threads und synchronized

[redbomber]

Hi zusammen,

ich stehe gerade vor einem Problem und möchte eure Meinung dazu hören.

Ich besitze eine Liste auf die von einem GUI-Thread und von einem oder mehreren nicht-GUI-Threads aus drauf zugegriffen wird.
Aus dieser Liste können Objeckte entfernt werden. Da könnt ihr euch ja vorstellen was passiert.

Welche Lösungen habe ich:
1. alle Methoden die auf die Liste zugreifen synchronized machen
2. immer ein deep-copy der Liste erstellen, auf diese dann alle Threads drauf zugreifen lassen

Probleme der Lösungen:
1. Mir wurde geraten nicht überall einfach synchronized zu machen, aber warum? (deadlocks?)
2. - man arbeitet evtl. auf einem bereits gelöschten Objekt der Liste
- man legt immer neue Listen an --> schlechte performanz und viel speicher


Könnt ihr mir vielleicht was dazu sagen?

 

[SlaterB]

1. überall blind synchronized ist offensichtlich schlecht, das heißt aber nicht dass es an sinnvollen Stellen verboten ist
2. alles richtige Argumente, ob das für dich wichtig ist musst du selber wissen,
allgemein kann man aber auch behaupten, dass einmal repaint() mehr Zeit verbraucht als dein Programm in einem Jahr Laufzeit anteilig fürs Kopieren kleiner Listen benötigt

 

[Noctarius]

Statt synchronized kann man oft auf den weniger "teuren" ReentrantLock nutzen (bzw eine alternative Lock-Implementierung). Das concurrent-Package kennt da eine ganze Menge Arten.

 

[jule37]

java.util.Vector ist thread safe

 

[Noctarius]

Argh man empfiehlt keinem Vector, außer man ist Professor und hört sich gerne selber reden. Vector setzt genau das Prinzip um was er wollte "sinnlos alles synchronisiert".

 

[maki]

... und dabei eben doch nicht alles synchronisiert, wie zB. beim Iterieren, und deswegen nicht komplett threadsafe ist, auch Vector wirft die ConcurrentModificationException.

Als Alternative kommen vielleicht das ConcurrentSkipListSet in Betracht, brauchen mehr Speicher, aber keine zusätzliche synchronisation.

 

[tfa]

Vector wirft die ConcurrentModificationException.

Das hat auch grundsätzlich nichts mit Threading zu tun (obwohl es meist dort auftritt).

 

[redbomber]

hmm ok,
also das vorgeschlage Set ConcurrentSkipListSet wäre dann eine Alternative zu meiner deep-copy-Liste.

Alternativ habe ich mir noch eine dritte Lösung überlegt.
Ich könnte in meinem Objekt, auf das alle Threads zwecks der Liste zugreifen auch die Methoden mit
EventQueue.invokeAndWait() ausführen.
Da diese Objekt bei mir eigentlich ein Model für die GUI ist, ist das zumindest nicht "unkorrekt" in dieser Klasse die EventQueue aufzurufen.

Was erreiche ich:
- Eigentlich das gleiche wie bei synchronized!?
Probleme:
- auch hier Gefahr von deadlocks?

Welche Lösungen habe ich:
1. alle Methoden die auf die Liste zugreifen synchronized machen
2. immer ein deep-copy der Liste erstellen, auf diese dann alle Threads drauf zugreifen lassen
3. EventQueue.invokeAndWait()

Probleme der Lösungen:
1. Mir wurde geraten nicht überall einfach synchronized zu machen, aber warum? (deadlocks?)
2. - man arbeitet evtl. auf einem bereits gelöschten Objekt der Liste
- man legt immer neue Listen an --> schlechte performanz und viel speicher

 

[Samuel72]

Hallo Redbomber,

was ich auch schon mal gemacht habe:
Eine verkette Liste selber implementieren,
und dann bei den add bzw. remove - Befehlen die Zeiger so umhängen,
dass ein evtl. gleichzeitig darüberlaufender zweiter Thread nicht ins Leere rauscht.

 

[Marco13]

Ist schwer pauschal zu beantworten. Man könnte sich auch überlegen, eine Kopie vorzuhalten, und ggf. die Änderungen da rein zu übertragen. Relevant wäre aber auch, welche Threads wann was mit der Liste machen. Der GUI-Thread liest nur, die anderen schreiben auch - d.h. sie müssen ja schon untereinander irgendwie sysnchronisiert sein...?

 

[redbomber]

also die beste Lösung bei mir wäre wohl ein komplett neues Model zu erstellen, welches sich um die Synchronisierung kümmert.
Darauf greift dann der GUI-Thread und die anderen Threads.
Aktuell ist es bei mir aber nicht möglich das zu ändern.

was ich auch schon mal gemacht habe:
Eine verkette Liste selber implementieren,
und dann bei den add bzw. remove - Befehlen die Zeiger so umhängen,
dass ein evtl. gleichzeitig darüberlaufender zweiter Thread nicht ins Leere rauscht.

Das mit der verketteten Liste finde ich auch nicht schlecht. Dann müsste ich aber auch neue Schnittstellen zur Verfügung stellen, damit die Threads über die Elemente der Liste iterieren können.

Ist schwer pauschal zu beantworten. Man könnte sich auch überlegen, eine Kopie vorzuhalten, und ggf. die Änderungen da rein zu übertragen.

Das mit der deep-copy hatte ich auch überlegt. Bin damit aber sehr unzufrieden, da alle Änderungen wie du schon sagst übertragen werden müssen. Wehe man vergisst hier was...

Relevant wäre aber auch, welche Threads wann was mit der Liste machen. Der GUI-Thread liest nur, die anderen schreiben auch - d.h. sie müssen ja schon untereinander irgendwie sysnchronisiert sein...?

Naja, gute Frage. AUsserhalb von meinem Objekt kracht es nie. ich hab in meinem Objekt immer das Problem wenn zb. so über eine Liste iteriert wird:

for(int i = 0; i < getObjectNumber(); i++){
    Object object = getObject(i); // hier krachts, da sich die getObjectNumber() geändert hat
    ...
}

Aktuell mache ich folgendes:
mit EventQueue.invokeAndWait erstelle ich eine neue Liste in der sich die Referenzen zu den Objekten befinden (also kein deep-copy).
Auf dieser kopierten Liste arbeiten dann die Threads. Wird eines der Objekte in der Liste gelöscht, dann können die Threads weiterarbeiten ohne ins leere zu laufen. Sie greifen evtl. auf ein Objekt zu welches in der "originalen" Liste nicht mehr vorhanden sind. Wenn ich mit diesem Problem leben kann wäre es doch ok, oder?
Oder hab ich hier einen Denkfehler und kann auch hier einer der Threads ins leere laufen?
(Nebenfrage: falls ein Objekt der "originalen" Liste gelöscht wird, dann besteht das Objekt ja noch immer, da in der kopierten Liste noch die Referenz zum Objekt besteht.)

 

[Marco13]

So ganz kapier' ich's nicht: Was hat die invokeAndWait genau damit zu tun?

 

[redbomber]

also bisher hatte ich die folgende Methode:

class MyModel{
public List<MyObject> getObjects(){
List<MyObject> objects = new ArrayList<MyObjects>();

         for(int i = 0; i < getNumberOfObjects(); i++){
             objects.add(getObject(i)); //hier kams zum Fehler wenn ein Thread ein Object von MyModel entfernt hat
         }
return objects;
}}

Um dieses Problem zu eliminieren mache ich nun folgendes:

class MyModel{
public List<MyObject> getObjects(){
final List<MyObject> objects = new ArrayList<MyObjects>();

       try {
			EventQueue.invokeAndWait(new  Runnable() {
				
				@Override
				public void run() {
					for(int i = 0; i < getNumberOfObjects(); i++){
                                              objects.add(getObject(i));
                                        }
				}
			});
		} catch (Exception e) {
			return ArrayList<MyObjects>();
		}
         
return objects;
}}

D.h. ich möchte das alle anderen Threads warten während ich meine Liste erzeuge.
Zwar könnte es sein dass die Liste die ich zurück gebe dann kurz darauf Elemente enthält welche schon gelöscht wurden,
aber dafür kann die Liste ohne Fehler erzeugt werden.

 

[Marco13]

Ahrg... Die synchronisation besteht dann ja darin, dass ALLE Threads ihre Arbeit vom Event-Dispatch-Thread erledigen lassen :autsch: Natürlich gibt's dann keine Probleme (weil ja alles von EINEM Thread gemacht wird) aber das ist weit weg von "sinnvoll".

Also... Es geht also darum, dass es eine Klasse gibt

class MyModel
{
    private List<Object> objects = ...
   
    public int getNumObjects() { ... }
    public Object getObject(int i) { ... }
    public List<Object> getObjects() { ... } // Soll eine Kopie der Liste zurückgeben

    // Die hier könnte von einem anderen thread aufgerufen werden,
    // WÄHREND "getObjects" die aktuellen Objects sammelt (und 
    // dann würde es krachen)
    public void removeObject(int i) { ... }

Stimmt das so weit?

 

[SlaterB]

Ahrg... Die synchronisation besteht dann ja darin, dass ALLE Threads ihre Arbeit vom Event-Dispatch-Thread erledigen lassen :autsch: Natürlich gibt's dann keine Probleme (weil ja alles von EINEM Thread gemacht wird) aber das ist weit weg von "sinnvoll".

nicht in jeder Hinsicht, wenn man an nur eine CPU denkt wird sowieso letzlich alles von nur einer Komponente durchgeführt,
mehrere CPUs gibts noch nicht so lange und ob die überhaupt sinnvoll genutzt werden..

die organisatorische Aufgabe der Trennung von Code kann dabei durchaus noch einigermaßen erhalten bleiben

 

[Marco13]

Hm. Mindestens 2 Cores hat heute wohl "jeder", und man kann davon ausgehen, dass Java die auch nutzt, wenn man mehrere Threads erstellt. Und inwieweit man von "Organisatorischer Trennung" reden kann, wenn diese Threads anscheinend alle das gleiche machen, weiß icht nicht. Aber vielleicht hat der TO noch mehr infos dazu.