SWT[5]#2

[Thomas]

wollte mal fragen ob es bei der 2)b) an der if-else konstruktion liegt dass die barriere nicht richtig funktioniert, da man ja eigetlich die bedingung immer vor und nach wait() checken soll und die eigentliche bedingung ja arrived < cnt ist. wobei das problem durch externe notifyAll() ja eigentlich nicht besteht da threads nur entkommen können, wenn arrived = 0 ist oder? oder gibts da ein ganz andre problem dass mir jetzt so nicht aufgefallen ist.
und bei der a) wollte ich fragen, ob mit ner ungünstigen aufteilung auch gemeint ist, wenn von beispielsweise 4 threads nur die ersten 3 arbeit verrichten mit einer blockgröße von 3 beispielsweise.

[markusj]

Ein Tipp zur b): Sieh dir an was passiert, wenn du die Barriere wiederverwendest.

mfG
Markus

[Dre]

Hm, also hier stoß ich grad auch auf ne gestige Schranke...
Wenn ich die Barriere also in z.B. ner Schleife verwende, wo liegt denn da das Problem?

[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

[Christian S.]

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

Alternativ kannst du die Situation betrachten, die auftritt, wenn du die Barriere für mehr Threads als das Limit des Barrieren-Überlauf benutzt und die Barriere als eine Art Zwischensperre /Flaschenhals verwendest.

[Cauchy]

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?

[Thomas]

so weit ich das verstanden wird ein thread mit wait() einfach stillgelegt und die methode bzw der synchronisierte abschnitt wieder freigegeben, es kann also der nexte thread darauf zugreifen.

[Cauchy]

Ja, genau, dass habe ich auch grade rausgefunden

Ja, aber der Thread wird ja stillgelegt, bis wieder notifiy() oder notifyall() aufgerufen wird, demnach kann es doch gar nicht vorkommen, dass ein Thread zweimal die Barriere betritt oder irre ich mich da grade?

[Thomas]

ich habs jetzt so verstanden dass durch eine schleife eine neue gruppe von threads gestartet wird während die erste gruppe von threads noch nicht abgearbeitet ist. dadurch wkönnte es dann passieren dass ein thread der 2. gruppe auf die barriere zugreift und den zähler erhöht wodurch das ergebnis der ersten gruppe verfälscht werden würde.

[Cauchy]

ich habs jetzt so verstanden dass durch eine schleife eine neue gruppe von threads gestartet wird während die erste gruppe von threads noch nicht abgearbeitet ist. dadurch wkönnte es dann passieren dass ein thread der 2. gruppe auf die barriere zugreift und den zähler erhöht wodurch das ergebnis der ersten gruppe verfälscht werden würde.

Mhh, das ganze finde ich noch ein bisschen komisch. Wenn man eine neue Gruppe von Thread startet, warum benutzt man dann nicht gleiche eine neue Barriere?
In diesem Fall dann einfach eine neue Instantz der Klasse Barrier.

Wie hast du das Problem im Quellcode gelöst?