SWT[5]#2
-
- Administrator
- Beiträge: 383
- Registriert: Do 23. Okt 2008, 20:16
- Wohnort: Karlsruhe
- Kontaktdaten:
SWT[5]#2
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.
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.
Re: SWT[5]#2
Ein Tipp zur b): Sieh dir an was passiert, wenn du die Barriere wiederverwendest.
mfG
Markus
mfG
Markus
Re: SWT[5]#2
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?
Wenn ich die Barriere also in z.B. ner Schleife verwende, wo liegt denn da das Problem?
Cheers André
Re: SWT[5]#2
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
-
- Beiträge: 225
- Registriert: Sa 25. Okt 2008, 12:48
Re: SWT[5]#2
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.elTybbq hat geschrieben: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
Re: SWT[5]#2
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?elTybbq hat geschrieben: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
-
- Administrator
- Beiträge: 383
- Registriert: Do 23. Okt 2008, 20:16
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: SWT[5]#2
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.
Re: SWT[5]#2
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?
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?
-
- Administrator
- Beiträge: 383
- Registriert: Do 23. Okt 2008, 20:16
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: SWT[5]#2
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.
Re: SWT[5]#2
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?Thomas hat geschrieben: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.
In diesem Fall dann einfach eine neue Instantz der Klasse Barrier.
Wie hast du das Problem im Quellcode gelöst?