Optimisation ReaderWriterLock accès en lecture

Question

Alors, je crois savoir que sur un ReaderWriterLock (ou ReaderWriterLockSlim plus précisément), à la fois la lecture et de l'écriture ont besoin d'acquérir un mutex pour prendre le verrou. Je voudrais optimiser l'accès en lecture de la serrure, de sorte que s'il n'y a pas écritures en attente, aucune serrure ne doit être acquis. (Et je suis prêt à sacrifier la performance des écritures, ajouter quelques contraintes à la lit, faire la première lecture lente et deuxième rapide, etc .. si nécessaire, tant que la grande majorité des lectures sont aussi vite que possible. )

Alors, comment peut-on faire, ou mieux encore, est-il un cadre ou la mise en œuvre « standard » pouvait me pointer? (Ou si je l'ai mal compris et il est soutenu déjà, super!)

Donc, pour ma pièce: Il semblerait que si l'on devait avoir un compteur pour le nombre de lecteurs / écrivains (protégé par Interlocked.Increment), ce serait suffisant pour le lecteur pour vérifier si le compte écrivain était non nul, et d'acquérir uniquement la serrure puis . (Et incrément dans le verrou si acquis.)

Les auteurs seraient toujours incrémenter, acquérir le verrou, tourner jusqu'à ce que le nombre de lecteurs est allé à 0 (prêt à assumer les lecteurs finissent toujours rapidement, ou même contourner le lecteur comptent entièrement dans un scénario optimiste), et enfin diminuer la valeur. (Ce serait bien de jeter une priorité de forme trop quand nous faisons bloc, ou tous les lecteurs / écrivains en attente potentiellement claires en une seule passe depuis que je suis seulement protéger une valeur, mais je vais renoncer que pour l'instant ..)

.. Quelqu'un a vu quelque chose de semblable ou une suggestion? S'il n'y a rien là-bas après un peu, je serais heureux de jeter ensemble une mise en œuvre initiale et parler plus concrètement.

Answer 1

Ce que vous avez décrit est, à un niveau de base, déjà comment les serrures du lecteur / enregistreur de travail. Ils ne ont pas besoin de prendre un mutex comme le lecteur / verrouiller l'accès aux commandes de l'écrivain en utilisant un compte interne des lecteurs et des écrivains (et, en effet, un mutex impliquerait que les lecteurs se bloquer les uns les autres, alors qu'en fait, plusieurs lecteurs simultanés sont permis -. qui est toute la question du type de verrouillage)

Alors oui, il y a un cadre / mise en œuvre standard pour cela: ReaderWriterLockSlim. Je doute vraiment que vous serez en mesure d'écrire un verrou de lecture / écriture avec une meilleure performance que cela. Dans tous les cas - êtes-vous sûr que ce verrou est la racine de vos problèmes de performance

?

Answer 2

Je crains que vous avez tort, car ReaderWriterLockSlim est basé sur le verrouillage de rotation, pas sur les mutex (vous pouvez voir ce réflecteur).