Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
8.4 Barriers
Ich stehe gerade total auf dem Schlauch…
Also meine CountdownBarrier funktioniert.
Die AlternatingBarrier soll doch genau das selbe können wie die CyclicBarrier oder?
Wozu braucht man denn diese Phasen?
Mittlerweile komme ich mit den ThreadLocal objekten zurecht. Jeder Thread erhält jetzt beim betreten der await()-Metode einen boolean phase, der eben immer true oder false ist. Wenn size=4 und der 5. thread ruft await() auf dann bekommt er false, die vier davor true usw. immer abwechselnd.
Aber wozu das ganze?
Wieso macht man das nicht genau so wie bei Countdown-Barrier, bloß dass dann der Counter wieder hochgesetzt wird?
EDIT: Kaum postet man es hier läuft es natürlich…
Und ich steh immer noch auf dem Schlauch…
Man kann ja den Counter nicht einfach wieder hochsetzen und ne einfache Abfrage beim aktiven Warten wie “Counter== 0” machen, da es dann sein kann, dass ein Thread den Counter wieder hochsetzt und die anderen Threads es garnicht “mitbekommen”, dass der Counter auf 0 gestanden ist, richtig?
Was genau soll ich dann mit den ThreadLocal Objekten anfangen? Damit sehe ich doch nur, welcher Thread den Counter hochsetzen muss. Dann muss man den anderen wartenden Threads aber trotzdem irgendwie Bescheid geben, dass sie nicht mehr warten müssen.
nein, dachte auch erst, dass diese ThreadLocal Objekte sinnlos sind.
Aber du kannst darin speichern, zu welcher “Ladung” sie gehören.
kleines beispiel:
AtomicInteger atomic = new Atomicinteger(0);
ThreadLocal<Integer> ThreadID = new ThreadLocal(){
@Override
protected Integer initialValue(){
return atomic.getAndIncrement();
}
};führst du jetzt irgendwo in der Klasse ThreadID.get() aus, so bekommst du automatisch eine aufsteigende und einzigartige ThreadID, ohne dass du dich um etwas kümmern musst.
Das ist sehr hilfreich zur beseitigung des von dir genannten Problems
1 Like
Genau an diesem Problem sitze ich auch noch. Mit dem ThreadLocal-Objekt wird doch extra eine neue Instanz des Objekts instanziiert, d.h. notify und wait dürften nicht mehr funktionieren? Oder verirre ich mich da in einem Denkfehler?
Ich verstehe auch nicht genau wo die ThreadLocal Variable angelegt werden soll, ich muss ja sofern ich das richtig verstehe in jedem Thread eine Variable anlegen die festlegt ob er noch an der alten oder schon an der neuen Barrier hängt. Nun hab ich aber nur die Barrier zum bearbeiten nicht den Thread. Wie kann ich ueberhaupt aus der Barrier heraus Variablen in jedem Thread erzeugen ?
Ich steh auch auf dem schlauch, evtl. kann ein Tutor einen Tipp geben ?
Danke
Bass
Wenn du ThreadLocal in der Barrier verwendest, sieht jeder Thread sein eigenes ThreadLocal Objekt. Das läuft automagisch ;).
Notify und wait braucht man für die Aufgabe sowieso nicht, ich würde in diesem Fall in einer Schleife aktiv warten .
Die Schleifenbedingung sollte die geraden und ungeraden Phasen berücksichtigen 
.
Guten Abend,
muss man eigentlich nur die await()-Methode implementieren oder auch die Methoden Countdown(),getCount(), usw.?
Und wie greife ich denn dann auf den jeweiligen Thread zu, den ich solange warten lassen muss, bis ich zur 0 runtergezaehlt habe?
Vielen Dank für Antworten!
Mr.
Die await() Methode reicht.
Gar nicht direkt. Jeder Thread ist für sich selber verantwortlich.
Es muss lediglich await() implementiert werden. Hier zählst du einen counter herunter und wartest anschließend aktiv in einer Schleife.
Okay, danke! Und wie mach ich das, dass die Threads dann wieder an ihre Arbeit gehen?
Indem du sie in der await()-Methode aktiv auf die Erfuellung ener Bedingung warten laesst.
Achso, und wenn diese erfüllt ist, gehen sie praktisch automatisch wieder an ihre Arbeit? Heisst aktiv, dass ich sie nicht mit timeunit schlafen lasse?
Ja. Aktiv Warten ist sowas wie [m]while (!done) { /* nothing */ }[/m], ob aktives Warten in diesem Fall geschickt ist, ist eine andere Frage.