SWT[5]#2

[Thomas]

habs selbst noch nicht bearbeitet weil ich mir da auch nicht wirklich sicher bin, ob das stimmt wie ichs verstanden habe. hab mich bisher auch eher mit der aufgabe 3 beschäftigt, da ich noch keine gute möglichkeit gefunden habe auf das ende eines pools zu warten ohne awaitTermination zu verwenden.

[elTybbq]

es kann halt passieren, dass ein Thread zum zweiten Mal die Barriere betritt, wenn noch nicht alle Threads vom ersten Mal die Barriere wieder verlassen haben... und dann is blöd

Es wird doch aber nirgendwo behauptet, dass man die Barrier wiederverwenden soll. In Java gibt es die Klasse CyclicBarrier, das cyclic bedeutet ja grade, dass man sie wiederverwenden kann, aber kann man daraus schließen, dass diese Barrier auch wiederverwendbar ist?

Genau das find ich auch komisch aber nen anderen Fehler finde ich halt nicht.

Nochmal zum Problem: Das Problem tritt auch (vor allem) auf wenn man die Barriere mit der selben Gruppe von Threads zweimal benutzt, z.B: angenommen, es gibt 10 Threads. Thread 1 betritt als letzter die Barriere, arrived wird auf 0 gesetzt und notifyAll() wird aufgerufen. Jetzt verlassen vielleicht Threads 1-3 nacheinander die Barriere, aber es ist nicht sichergestellt, dass alle Threads die Barriere verlassen, bevor irgendwas anderes gemacht wird. Es kann also spontan z.B. in Thread 1 weitergehen, während Thread 4-10 noch in der Barriere sind. Wenn jetzt in Thread 1 nochmal sync() aufgerufen wird, tritt Thread 1 nochmal in dieselbe Barriere ein, arrived wird inkrementiert und Threads 4-10 können die Barriere nicht mehr verlassen