• Fach: Concurrent Systems, 5ECTS
• Prüfer: wosch
• Beisitzer: Stefan
• Dauer: 20min
• Semester: WS19/20

• F: Wir hatten ja nicht-blockierende/blockierende Synchronisation, was ist da der Unteschied?
• A: Bei blockierender wird der Verdraengte Prozess verzoegert, bei nichtblockierender zum wiederholen der Operation gezwungen.
• F: Was wollen wir den machen?
• A: Lieber blockierende.
• F: Ok, wie kann man denn ein einfaches Lock bauen?
• A: [TAS-lock mit Erklaerung auf den Zettel skizziert.]
• F: Was fuer Probleme hat man hier?
• A: [Cache Trashing erklaert, False Sharing erklaert] Bus Lock wird beim kompletten RMW Zyklus gehalten, daher wird der Bus stark belastet und es kann zum Stau (Contention) kommen.
• F: Mit CAS kann man das ja besser machen, warum?
• A: Es wird nur geschrieben wenn der Wert uebereinstimmt, beim TAS wird immer geschrieben (auch wenn der Wert eh der gleiche ist). Cache Trashing wird also geloest, Bus-Contention bleibt aber.
• F: Welches Problem hat man bei CAS denn eventuell?
• A: ABA Problem, das ist wenn der Wert zwar der gleiches ist aber die Bedeutung sich in der Zwischenzeit veraendert hat. Z.B. bei einem Pointer der zwar auf die gleiche Stelle zeigt aber wo sich der Inhalt der Stelle auf die gezeigt wird veraendert hat.
• F: Wie kann man das loesen?
• A: Etweder hat man LL/SC oder man nimmt Generationszaehler.
• F: Aber ist es dann mit Generationszaehler wirklich endgueltig geloest?
• A: Ne, nur sehr unwahrscheinlich weil der kann immer noch ueberlaufen.
• F: Wir haben ja dann Backoff verfahren eingebaut, welches war denn da das beste?
• A: Proportionaler Backoff beim Ticket Lock.
• F: Wie funktioniert das Ticket Lock allgemein?
• A: [Ticket Lock Code ohne Backoff auf Zettel skizziert und erklaert.]
• F: Was ist denn abgesehen vom Cache Trashing/Bus Lock der Unterschied zwischen Ticketlock und CAS/TAS Lock?
• A: Fairness. Beim CAS/TAS-Lock koennen sie verhungern, dafuer ist aber eventuell der Durchsatz hoeher. Kommt auf den Anwendungsfall an was besser ist. Wenn alle Threads gleich sind z.B. macht Fairness keinen Unterschied, hat man aber z.B. Producer und Consumer braucht man unter Umstaenden Fairness.
• F: Und wie passt der Backoff ins Ticketlock rein?
• A: [Stand auf dem Schlauch weil ich in dem Moment nicht gecheckt habe warum man ueberhaupt Backoff beim Ticketlock brauchen sollte. Etwas erklaert wie das Ticket lock funktioniert. Sind drauf gekommen das sie alle auf der gleichen Variable spinnen.]
• F: Was kann man denn noch besser machen?
• A: [Stand etwas auf dem Schlauch.]
• F: In der Uebung habt ihr doch etwas mit einem Queued-Lock gemacht? [Schaut Stefan an um sicherzugehen das wir das auch wirklich gemacht haben.]
• A: [Habs garnicht gecheckt weil ich stat „queued“ „cute“ verstanden habe.]
• F: Wie kann man denn verhindern, dass sie alle auf die gleiche Variable warten. Besser waere z.B. dass jeder nur auf seinen Vorgaenger wartet.
• A: [Da hab ichs gecheckt.] Man kann eine Art verlinkte Liste bauen. Neue wartende haengen sich hinten ein und wenn man fertig ist setzt man die Variable auf die der Nachfolger wartet z.B. auf true. So warten sie nicht alle auf die gleiche. [Siehe MCS Lock in der Uebung.] Hab auf den Zettel grob eine List mit „Wartet-Auf“ Abhaengigkeiten skizziert. [Wie genau das im Code funktioniert hatten wir keine Zeit mehr aber die Idee hat ihm schon gereicht.]

1.1, aber das können sie nicht vergeben meinte er, also 1.0. Wenn ich am Ende das mit dem MCS Lock nicht noch auf den Zettel gemalt haette waere es z.B. 1.3 gewesen meinte er.