Il y a beaucoup de choses écrites sur la classe ReaderWriterLockSlim qui permet une lecture multiple et une seule écriture. Tous ces éléments (du moins que j'avais trouvé) indiquent comment l'utiliser sans expliquer pourquoi et comment cela fonctionne. L'échantillon de code standard est le suivant: La question est la suivante: si la serrure évolutive permet uniquement à un seul thread de saisir sa section, pourquoi je devrais appeler la méthode En Enterwritelock dans? Que va-t-il se passer si je ne le fais pas? Ou ce qui va se passer si au lieu d'EnterupGradeablereadLock, j'appellerai En Enterwritelock et écrira à une ressource sans utiliser de verrouillage utile? P> p>
3 Réponses :
La classe ReaderWriterLockSlim s'effectue essentiellement le verrouillage de l'écriture et permet à tous les lecteurs de lire tant que le verrouillage de l'écriture n'est pas tenu. Une fois que le verrou d'écriture est maintenu, aucun lecteur ne peut lire. P>
L'idée derrière le Enterupgradeablereadock est simplement de permettre au programmeur d'indiquer explicitement leur intention et de ne pas modifier accidentellement des choses. P>
PM100 - Il est plus rapide car un verrou n'est pas exclusif, car de nombreux threads peuvent lire à la fois, ce qui peut accélérer les applications lourdes. En fait, si votre application est écrite, cela pourrait ne pas être la meilleure solution de verrouillage pour vous. Cela fonctionne mieux lorsque des modifications sont rarement fabriquées mais de nombreuses lectures sont nécessaires. P>
Vous dites que le EnterupgradeablereadADLOC est destiné uniquement à expliciter et que théoriquement peut être remplacé par Enterwritelock?
Intérieurement. Si vous utilisez simplement Enterwritelock, il bloquera les lecteurs afin qu'il ne soit pas bon de le faire.
Si le verrouillage utile ne permet que un un seul fil à entrer dans sa section, pourquoi je devrais appeler Enterwritelock Méthode à l'intérieur? P> blockQuote>
enterwritelock code> bloquerait d'autres threads à lire - si vous utilisez un verrou amélioré, d'autres threads peuvent toujours obtenir des serrures en lecture. À partir du
Enterupgradablock code> une documentation: p>
Un seul thread peut entrer une mise à niveau mode à un moment donné. Si un fil est en mode évolutif, et il n'y a pas de Fils en attente d'entrer en mode d'écriture, Tout nombre d'autres threads peut entrer mode de lecture, même s'il y a des threads En attente d'entrer en mode mis à niveau. em> p> blockQuote>
L'EnterpGradeablera-t-il pas également bloquer tous les filets jusqu'à ce qu'il quitte?
Nope, je vais mettre à jour ma réponse avec la partie pertinente de la documentation.
L'avantage de l'utilisation de en même temps, il ne les pas em> les appels bloqués sur < Code> entereadlock code>, d'autres threads peuvent toujours obtenir un accès en lecture dans d'autres parties du code (et ces appels bloquent bien sûr l'appel à Entrépgradeablereadlock code> sur
enterreadlock code> Est-ce que vous pouvez savoir si la condition que vous vérifiez afin de déterminer s'il faut entrer la serrure d'écriture ou non Ne changez pas entre vérifier la condition et entrer en réalité dans la serrure d'écriture. Cela évite la duplication qui peut être nécessaire avec un verrouillage
régulier code> S:
enterwritelock code> jusqu'à ce qu'ils libèrent les serrures de lecture) . p> p>
Merci à tous! Comme je peux accepter une seule réponse, j'ai choisi (subjectivement) celui-ci comme aussi informatif.