Frage zu Threads und Sperren

Ich lese gerade Fuss, Futexes und Furwocks: Fast Userland Locking unter Linux und bin auf dieses Zitat gestoßen :

In einem fairen Schließschema wird die Sperre in der Reihenfolge gewährt, in der sie angefordert wurde. Dies kann sich aufgrund der erhöhten Anzahl von Kontextwechseln negativ auf den Durchsatz auswirken. Gleichzeitig kann es zum sogenannten Konvoi-Problem kommen. Da die Sperren in der Reihenfolge ihres Eintreffens gewährt werden, werden alle mit der Geschwindigkeit des langsamsten Prozesses ausgeführt, wodurch alle Wartevorgänge verlangsamt werden. Eine übliche Lösung für das Konvoi-Problem bestand darin, das bei der Freigabe verfügbare Schloss zu markieren, alle Wartevorgänge zu aktivieren und sie erneut für das Schloss zu aktivieren. Dies wird als zufällige Fairness bezeichnet. Dies führt jedoch auch zu dem donnernden Herdenproblem. Trotzdem kann es auf Uniprozessorsystemen gut funktionieren, wenn die erste Aufgabe, die aktiviert wird, die Sperre aufhebt, bevor sie vorab festgelegt oder geplant wird, sodass das zweite Herdenmitglied die Sperre erhalten kann, usw.

Ich habe ein paar Fragen zu diesem Zitat.

Erstens: Führt ein faires Sperrschema zu einer erhöhten Anzahl von Kontextwechseln, da verschiedene Aufgaben Prozesse zu unterschiedlichen Zeiten in die Warteschlange stellen. Wenn also Prozesse in der Reihenfolge bedient werden, in der sie empfangen wurden, würden wir den Kontext zwischen mehreren Aufgaben wechseln.

Zweitens, wie führt das Gewähren von Sperren in der Reihenfolge des Eintreffens dazu, dass Prozesse mit der Geschwindigkeit des langsamsten Prozesses ablaufen? Wäre dies nicht nur der Fall, wenn dem langsamsten Prozess die Sperre vor den anderen Prozessen gewährt wird? Wie löst es das Konvoi-Problem, wenn Prozesse zufällig um die Sperre kämpfen?

Schließlich verstehe ich nicht, wie zufällige Fairness auf Uniprozessorsystemen im Vergleich zu Multiprozessorsystemen besser ist. In beiden Fällen werden zum Beispiel alle wartenden Prozessoren aufgeweckt, einer bekommt das Schloss und die anderen müssen wieder einschlafen, oder? Wie funktioniert das auf Uniprozessorsystemen?

Lassen Sie mich zuerst die letzte Frage beantworten. Es wird darauf hingewiesen, dass das Papier im Jahr 2002 geschrieben wurde, als Mehrkernprozessoren viel teurer waren. Ich denke, die Autoren waren hauptsächlich mit der Optimierung für den Single-Core-Fall befasst.

... wie [ist] zufällige Fairness ... auf Uniprozessorsystemen besser als auf Multiprozessorsystemen.

Auf einem Uniprozessor kann jeweils nur ein Prozess geplant werden. Jeder wird "aufgeweckt", aber das bedeutet nur, dass er von einem Wartezustand in einen Bereitschaftszustand versetzt wird. Dann wird der Scheduler aufgerufen und er wählt einen der auszuführenden Prozesse aus und lässt diesen Prozess für einen bestimmten Zeitraum laufen.

Als erstes erhält der neu ausgeführte Prozess die Sperre. Dann wird etwas verarbeitet und (wenn Sie kein Pech haben) wird die Sperre aufgehoben. In diesem Fall wählt der Kernel-Scheduler das nächste Mal, wenn er die Kontrolle erhält, einen anderen "Bereit" -Prozess und startet ihn. Wenn der erste Prozess die Sperre aufgehoben hat, wird sie vom zweiten Prozess erfasst und so weiter.

Auf einem Multiprozessor hingegen werden möglicherweise alle Prozesse "aufgeweckt", und dann startet der Scheduler einige / viele / alle gleichzeitig auf verschiedenen Prozessoren. Einer der Prozesse erhält die Sperre, aber alle anderen Prozesse versuchen, die Sperre zu erlangen, schlagen sofort fehl und setzen sich in der Warteschlange wieder in den Ruhezustand. Auf allen Prozessoren außer einem haben Sie nur mehrere Kernelaufrufe und mehrere Kontextwechsel verschwendet, damit Sie einer Reihe von Prozessen mitteilen können, dass nichts zu tun ist.

Führt ein faires Sperrschema zu einer erhöhten Anzahl von Kontextwechseln, da verschiedene Aufgaben Prozesse zu unterschiedlichen Zeiten in die Warteschlange stellen und wir also Prozesse in der Reihenfolge bedienen, in der sie empfangen wurden, würden wir den Kontext zwischen mehreren Aufgaben wechseln?

Ich denke, der Fall, an den sie denken, ist, wenn Sie mehrere Prozesse (auf einem Prozessor) haben, bei denen jeder Prozess für kurze Zeit wiederholt dieselbe Sperre erhält. Im unfairen Fall kann der erste Prozess eine Weile ausgeführt werden und die Sperre viele Male erwerben und aufheben, ohne einen Kontextwechsel durchzuführen. Dann läuft der zweite Prozess eine Weile und erwirbt und gibt die Sperre viele Male frei.

Im "fairen" Fall wird der erste Prozess gesperrt / freigegeben und dann beim zweiten Versuch, ihn zu sperren, in den Ruhezustand versetzt, und der Kernel muss einen Kontextwechsel durchführen und den anderen Prozess aktivieren. Die Prozesse Ping-Pong hin und her machen "Aufwachen, Sperren, Entsperren, ein wenig arbeiten, versuchen zu sperren, schlafen gehen".

Wie führt das Gewähren von Sperren in der Reihenfolge des Eintreffens dazu, dass Prozesse mit der Geschwindigkeit des langsamsten Prozesses ablaufen? Wäre dies nicht nur der Fall, wenn dem langsamsten Prozess die Sperre vor den anderen Prozessen gewährt wird? Wie löst es das Konvoi-Problem, wenn Prozesse zufällig um die Sperre kämpfen?

Ich denke, sie machen die Beobachtung, dass auf einem Uniprozessor Shortest-Job-First (unfair) kürzere durchschnittliche Wartezeiten hat als Round-Robin (fair). Aber ich verstehe nicht, wie zufällig die durchschnittlichen Wartezeiten im Vergleich zu Round-Robin verringert.