Het concept van lees-schrijf locks is eenvoudig, waarbij meerdere threads tegelijkertijd read locks kunnen verkrijgen, maar slechts één thread mag tegelijkertijd write locks verkrijgen, dus het wordt ook wel shared-exclusive locks genoemd. In C# wordt aanbevolen om de ReaderWriterLockSlim-klasse te gebruiken om de lees/schrijf-vergrendelingsfunctie te voltooien.
In sommige gevallen is het aantal leesbewerkingen naar een object veel groter dan het aantal aanpassingen, en als het simpelweg wordt vergrendeld door te vergrendelen, beïnvloedt dit de efficiëntie van het lezen. Als een lees-schrijfslot wordt gebruikt, kunnen meerdere threads het object tegelijk lezen, en het wordt alleen geblokkeerd wanneer het object door de schrijfvergrendeling wordt bezet.
Simpel gezegd, wanneer een thread in leesmodus gaat, kunnen andere threads nog steeds in leesmodus gaan; ervan uitgaande dat een thread op dat moment in schrijfmodus wil gaan, moet deze worden geblokkeerd. totdat de leesmodus afsluit.
Evenzo, als een thread in schrijfmodus gaat, worden de andere threads geblokkeerd, of ze nu willen schrijven of lezen.
Er zijn twee manieren om in de schrijf-/leesmodus te gaan:
EnterReadLock probeert de schrijfmodus-vergrendelingstoestand te bereiken.
TryEnterReadLock(Int32) probeert de leesmodus-vergrendelingstoestand te bereiken, met de optie om een gehele timeout te selecteren.
EnterWriteLock probeert de Write Mode Lock-toestand in te gaan.
TryEnterWriteLock(Int32) probeert de schrijfmodus-vergrendelingstoestand te bereiken, en de time-out tijd kan worden geselecteerd.
Er zijn 2 manieren om de schrijf-/leesmodus te verlaten:
ExitReadLock vermindert de recursieve telling van de leesmodus en verlaat de leesmodus wanneer de resulterende telling 0 (nul) is.
ExitWriteLock vermindert het recursieve aantal van het schrijfpatroon en verlaat de schrijfmodus wanneer de resulterende telling 0 (nul) is.
Zo gebruik je hem:
Je ziet dat thread 3 en thread 4 tegelijkertijd in leesmodus kunnen gaan, terwijl thread 5 na 5 seconden in schrijfmodus kan gaan (dat wil zeggen, nadat threads 3 en 4 de leesvergrendeling hebben verlaten).
Wijzig bovenstaande code, open eerst 2 threads in schrijfmodus en vervolgens threads in leesmodus, de code is als volgt:
De resultaten zijn als volgt:
Zoals je kunt zien, gaan thread 3 en thread 4 allebei in schrijfmodus, maar thread 3 neemt eerst de schrijflock in, dus thread 4 moet 10 seconden wachten voordat hij kan beginnen. Threads 5 en 6 moeten de read lock bezetten, dus wacht tot thread 4 de write lock verlaat voordat je verder gaat.
TryEnterReadLock en TryEnterWriteLock kunnen een timeout instellen; bij het uitvoeren van deze zin blokkeert de thread hier, als de lock op dat moment bezet kan zijn, returneert true, als de time-out de lock nog niet heeft bezet, returnt false, geeft de bezetting van de lock op en gaat door met het direct uitvoeren van de volgende code.
EnterUpgradeReadLock
De ReaderWriterLockSlim-klasse biedt een upgradebare leesmodus, die verschilt van de leesmodus doordat deze ook kan worden geüpgraded naar schrijfmodus door de methoden EnterWriteLock of TryEnterWriteLock aan te roepen. Omdat er maar één thread tegelijk in upgrade-modus kan staan. Een thread die in de upgradable mode gaat, beïnvloedt de thread in leesmodus niet, dat wil zeggen, wanneer een thread in de upgradebare modus gaat, kunnen elk aantal threads tegelijkertijd in leesmodus gaan zonder te blokkeren. Als meerdere threads al wachten om een schrijflock te verkrijgen, zal het uitvoeren van EnterUpgradeableReadLock blokkeren totdat die threads uitvallen of de schrijflock verlaten.
De volgende code laat zien hoe je kunt upgraden naar een schrijflock in de upgradebare leesmodus.
De impact van lees-/schrijfvergrendelingen op de prestaties is duidelijk.
De volgende testcode:
De bovenstaande code simuleert de werking van 500 taken, elk in een threadpool-thread, waarvan 20 schrijfthreads zijn en 480 leesthreads worden gesimuleerd. Het duurt 10 ms om data te lezen en 100 ms om te schrijven om respectievelijk de lock-methode en de ReaderWriterLockSlim-methode te testen. Voor ReaderWriterLockSlim kan een schatting worden gemaakt, ervan uitgaande dat 480 threads tegelijk worden gelezen, dan verbruikt het 10ms, 20 schrijfbewerkingen nemen 2000ms in beslag, dus de tijd die wordt gebruikt is 2010ms, en voor de gewone lockmethode, omdat ze allemaal exclusief zijn, nemen 480 leesoperaties 4800ms + 20 schrijfoperaties in beslag 2000ms = 6800ms. De resultaten toonden een merkbare prestatieverbetering.
|
Geplaatst op 09-03-2017 16:59:19
|
|
|
|
