Lese-/Schreibsperren
Aktualisiert: November 2007
Die ReaderWriterLockSlim-Klasse ermöglicht mehreren Threads, eine Ressource gleichzeitig zu lesen. Um in die Ressource zu schreiben, muss ein Thread jedoch auf eine exklusive Sperre warten.
Innerhalb einer Anwendung können Sie ReaderWriterLockSlim beispielsweise verwenden, um eine kooperative Synchronisierung der Threads zu ermöglichen, die auf eine freigegebene Ressource zugreifen. Sperren werden auf ReaderWriterLockSlim selbst angewendet.
Wie bei jedem Threadsynchronisierungsmechanismus müssen Sie sicherstellen, dass keine Threads die durch ReaderWriterLockSlim bereitgestellte Sperre umgehen. Eine Möglichkeit hierfür besteht darin, eine Klasse zu entwerfen, die die freigegebene Ressource kapselt. Diese Klasse würde Member bereitstellen, die auf die private freigegebene Ressource zugreifen und eine private ReaderWriterLockSlim zur Synchronisierung verwenden. Ein Beispiel hierzu finden Sie im Codebeispiel für die ReaderWriterLockSlim-Klasse. ReaderWriterLockSlim ist effizient genug, um zur Synchronisierung einzelner Objekte verwendet zu werden.
Strukturieren Sie Anwendungen so, dass die Dauer von Lese- und Schreibvorgängen minimiert wird. Lange Schreibvorgänge wirken sich in unmittelbarer Weise auf den Durchsatz aus, da die Schreibsperre exklusiv ist. Lange Lesevorgänge blockieren wartende Schreibvorgänge. Wenn mindestens ein Thread auf Schreibzugriff wartet, werden Threads, die Lesezugriff anfordern, ebenfalls blockiert.
.gif "Hinweis") Hinweis: |
|---|
.NET Framework verfügt über zwei Lese-/Schreibsperren: ReaderWriterLockSlim und ReaderWriterLock. ReaderWriterLockSlim wird für alle neuen Entwicklungen empfohlen. ReaderWriterLockSlim ist vergleichbar mit ReaderWriterLock, verwendet jedoch einfachere Regeln für die Rekursion sowie für das Herauf- und Herunterstufen des Sperrzustands. ReaderWriterLockSlim kann eine Vielzahl potenzieller Deadlocks vermeiden. Zudem wird mit ReaderWriterLockSlim eine deutlich höhere Leistung erzielt als mit ReaderWriterLock. |