Muss ich Sperrobjekt, wenn sie von ihm zu lesen?

Question

Ich schreibe ein Programm, in dem sie ein Objekt von mehreren Threads gemeinsam genutzt wird:

• A) Mehrere Schreib Threads auf das Objekt schreiben (alle laufen die gleichen Funktion)
• B) Ein Lese Threads, die alle 5 Sekunden Objekt zugreift
• C) Ein Lese Threads, das Objekt zugreift, gibt es eine Benutzeranforderung

Es ist offensichtlich notwendig, um das Objekt zu sperren, wenn es zu schreiben, da wir zur gleichen Zeit nicht mehrere Threads zu schreiben, um das Objekt werden sollen.

Meine Fragen sind:

1. Ist es auch notwendig, um das Objekt zu sperren, wenn von ihm zu lesen?
2. Bin ich richtig, dass denken, wenn wir nur das Objekt sperren, wenn Schreiben, ein kritischer Abschnitt ist genug; aber wenn wir das Objekt beim Lesen oder Schreiben zu sperren, ein Mutex ist notwendig?

Ich frage diese Frage, weil in Microsoft Office, ist es für zwei Instanzen von Word für den Zugriff ein Dokument im Lese- / Schreibzugriffsmodus nicht möglich ist; aber während das Dokument im Lese- / Schreibmodus geöffnet wird, ist es möglich, eine andere Instanz von Word öffnen Sie das Dokument im Nur-Lese-Modus zuzugreifen. Würde die gleiche Logik in Threading anwenden?

Answer 1

Wie Ofir schon schrieb - wenn Sie versuchen, Daten von einem Objekt zu lesen, dass ein anderer Thread modyfying -. Sie Daten in irgendeine inkonsistenten Zustand bekommen können

Aber - wenn Sie sicher sind, wird das Objekt nicht geändert wird, können Sie es natürlich von mehreren Threads gelesen. Im Allgemeinen ist die Frage, die Sie fragen, mehr oder weniger das Leser-Autoren Problem - siehe http: // en.wikipedia.org/wiki/Readers-writers_problem

Schließlich - ein kritischer Abschnitt ist ein abstrakter Begriff und kann mit einem Mutex oder einen Monitor implementiert werden. Die Syntax Zucker für einen kritischen Abschnitt in Java oder C # (synchronisiert, lock) einen Monitor unter der Bettdecke verwendet werden.

Answer 2

Es ist notwendig, weil sonst (außer Operationen atomar sind) Sie sein können, einen Zwischenzustand zu lesen.

Sie möchten mehrere Leser gleichzeitig ermöglichen, die eine (Bit) erfordert komplexere Art von Schloss.

Answer 3

  

Ist es auch notwendig, um das Objekt zu sperren, wenn von ihm zu lesen?

Wenn etwas anderes, um es zur gleichen Zeit schreiben kann - ja. Wenn nur könnte ein weiterer Lese auftreten - nein. In Ihren persönlichen Umständen, würde ich sagen - ja

.

  

Bin ich richtig zu denken, dass, wenn wir das Objekt nur sperren, wenn Schreiben, ein   kritische Abschnitt ist genug; aber wenn wir   sperrt das Objekt beim Lesen oder   Schreiben, ein Mutex ist notwendig?

Nein, können Sie einen kritischen Abschnitt für beide verwenden, andere Dinge gleich. Mutexes hat zusätzliche Funktionen über Abschnitte (benannt mutexes aus mehreren Prozessen verwendet werden, zum Beispiel), aber ich glaube nicht, dass Sie solche Merkmale hier benötigen.

Answer 4

1. hängt davon ab, wie Sie es verwenden und lesen. wenn Ihr Leseatom ist (das heißt, nicht durch Schreib unterbrochen werden) und der Lesefaden nicht über Abhängigkeit mit dem Schreib Threads, dann können Sie vielleicht Lesesperre überspringen. Aber wenn Ihre ‚lesen‘ Operation einige Zeit in Anspruch nimmt und nimmt schweren Gegenstand interation, dann sollten Sie es bis zum Lesen sperren.

2. Wenn Ihre Lesung nicht sehr lange dauert (das heißt, wird die Schreib Fäden nicht zu lange verzögern), sollte kritischen Abschnitt genug sein.

Answer 5

Verriegelung wird nur benötigt, wenn zwei Prozesse die gleichen Datenbanktabelle Elemente ändern können. wenn Sie möchten, um Daten zu lesen ist es immer zu sichern. Sie lesen Daten von einer konsistenten Datenbasis. der Prozess die Daten zu ändern hat eine Schattenversion, die konsistent ist und aktuellen Daten überschreiben, wenn Sie es speichern. aber wenn Sie einen Lesevorgang ausgeführt werden, die von Datenbankelementen auf kritischen Wert ist abhängig machen, sollten Sie für Schlösser suchen, die diese Werte wahrscheinlich geändert werden sollen, anzeigt. so wird Ihre Lese verzögert, bis die Sperre weg ist.