Wie kann man den "nicht fairen" Modus von ReentrantReadWriteLock verstehen?

8

ReentrantReadWriteLock hat einen fairen und nicht fairen (Standard) Modus, aber das Dokument ist so schwer für mich, es zu verstehen.

Wie kann ich es verstehen? Es ist großartig, wenn es ein Codebeispiel gibt, um es zu demontieren.

AKTUALISIEREN

Wenn ich einen Schreib-Thread habe, und viele viele Lese-Thread, welcher Modus ist besser zu verwenden? Wenn ich einen nicht-fairen Modus verwende, ist es möglich, dass der Schreib-Thread eine geringe Chance hat, die Sperre zu bekommen?

    
Freewind 01.11.2011, 03:58
quelle

2 Antworten

13

Nicht fair bedeutet, dass, wenn die Sperre für einen neuen Thread bereit ist, die Sperre keine Garantie für die Fairness des Zugriffs auf die Sperre gibt (vorausgesetzt, dass mehrere Threads die Sperre anfordern) damals). Mit anderen Worten, es ist denkbar, dass ein Thread ständig ausgehungert wird, weil es anderen Threads immer gelingt, die Sperre stattdessen willkürlich zu erhalten.

Der

Fair -Modus verhält sich mehr wie "Wer zuerst kommt, mahlt zuerst", wo Threads ein gewisses Maß an Fairness garantieren, dass sie das Schloss fair erhalten (zB vor einem Thread, der lange wartet) nach).

Bearbeiten

Hier ist ein Beispielprogramm, das die Fairness von Sperren demonstriert (da Schreibsperranfragen für eine faire Sperre zuerst kommen, zuerst bedient werden). Vergleichen Sie die Ergebnisse, wenn FAIR = true (die Threads sind immer in der Reihenfolge geliefert) im Vergleich zu FAIR = false (die Threads werden manchmal außerhalb der Reihenfolge ausgeführt).

%Vor%

Bearbeite (wieder)

In Bezug auf Ihr Update, mit nicht-fairen Sperren, gibt es nicht die Möglichkeit, dass ein Thread eine geringe Chance hat, eine Sperre zu erhalten, sondern dass die Wahrscheinlichkeit, dass ein Thread etwas warten muss, gering ist.

Nun, typischerweise, wenn die Hungerperiode ansteigt, sinkt die Wahrscheinlichkeit, dass diese Zeit tatsächlich auftritt ... genauso wie es 10 Mal hintereinander passiert, dass eine Münze "Köpfe" schlägt, ist es weniger wahrscheinlich, als eine Münze "Köpfe" 9 aufeinanderfolgend zu schlagen mal.

Aber wenn der Auswahlalgorithmus für mehrere wartende Threads etwas nicht-randomisiertes war, wie "der Thread mit dem alphabetisch-ersten Namen immer die Sperre bekommt", dann haben Sie möglicherweise ein echtes Problem, weil die Wahrscheinlichkeit nicht notwendigerweise als der Thread abnimmt wird mehr und mehr verhungert ... wenn eine Münze zu "Köpfen" gewichtet wird, sind 10 aufeinanderfolgende Köpfe im Wesentlichen genauso wahrscheinlich wie 9 aufeinanderfolgende Köpfe.

Ich glaube, dass bei nicht fairen Sperren eine etwas "faire" Münze verwendet wird. Die Frage wird also Fairness (und damit ) gegenüber dem Durchsatz. Die Verwendung einer nicht fairen Sperrung führt in der Regel zu einem besseren Durchsatz, jedoch zu Lasten gelegentlicher Latenzspitzen für eine Sperranforderung. Was für Sie besser ist, hängt von Ihren eigenen Anforderungen ab.

    
Mark Peters 01.11.2011, 04:01
quelle
0

Wenn einige Threads auf eine Sperre warten und die Sperre einen Thread auswählen muss, um Zugriff auf den kritischen Bereich zu erhalten:
Im nicht fairen Modus wird der Thread ohne Kriterien ausgewählt.
Im fairen Modus wird der Thread ausgewählt, auf den am meisten gewartet wurde.

Hinweis: Beachten Sie, dass das zuvor erläuterte Verhalten nur für die Methoden lock () und unlock () verwendet wird. Da die tryLock () -Methode den Thread nicht in den Ruhezustand versetzt, wenn die Lock-Schnittstelle verwendet wird, hat das fair-Attribut keinen Einfluss auf dessen Funktionalität.

    
zxholy 18.11.2013 15:27
quelle

Tags und Links