ReaderWriterLockSlim et Pulse/Wait

Question

Existe-t-il un équivalent de Monitor.Pulse et Monitor.Wait que je peux utiliser conjointement avec un ReaderWriterLockSlim?

J'ai une classe où j'ai encapsulé l'accès multi-thread à une file d'attente sous-jacente. Pour mettre en file d'attente quelque chose, j'obtiens un verrou qui protège la file d'attente sous-jacente (et quelques autres objets) puis ajoute l'objet et Monitor.Pulse l'objet verrouillé pour signaler que quelque chose a été ajouté à la file d'attente. À l'autre extrémité de la file d'attente, j'ai un seul thread d'arrière-plan qui traite les messages en continu lorsqu'ils arrivent dans la file d'attente. Il utilise Monitor.Wait lorsqu'il n'y a aucun élément dans la file d'attente, pour éviter une interrogation inutile. (Je considère cela comme un bon design, mais les flammes (raison) sont les bienvenus si elles me aider à apprendre autrement.)

private void DequeueForProcessing(object state) 
{ 
    while (true) 
    { 
     ITask task; 
     lock (mutex) 
     { 
      while (underlying.Count == 0) 
      { 
       Monitor.Wait(mutex); 
      } 
      task = underlying.Dequeue(); 
     } 
     Process(task); 
    } 
}

Comme plus d'opérations sont ajoutées à cette classe (nécessitant un accès en lecture seule à la serrure sous-jacent protégé), quelqu'un a suggéré d'utiliser ReaderWriterLockSlim. Je n'ai jamais utilisé la classe auparavant, et en supposant qu'elle puisse offrir des avantages de performance, je ne suis pas contre, mais seulement si je peux garder le design Pulse/Wait.

Answer 1

Après avoir joué un peu (et après avoir accepté le défi de Mark (Je suis d'accord, mon changement est pas exactement de base)) je suis venu avec cette combinaison:

ReaderWriterLockSlim rwls; 
AutoResetEvent are;

public void Enqueue(ITask task) { 
    rwls.EnterWriteLock(); 
    try { 
     underlying.Enqueue(task); 
     if (underlying.Count == 1) { 
      are.Set(); 
     } 
    } finally { 
     rwls.ExitWriteLock(); 
    } 
}

private void DequeueForProcessing(object state) { 
    while (true) { 
     ITask task; 
     rwls.EnterWriteLock(); 
     try { 
      while (underlying.Count == 0) { 
       rwls.ExitWriteLock(); 
       are.WaitOne(); 
       rwls.EnterWriteLock(); 
      } 
      task = underlying.Dequeue(); 
     } finally { 
      rwls.ExitWriteLock(); 
     } 
     Process(task); 
    } 
}

À ma œil non entraîné, il semble correspondre à la facture (même si c'est un peu plus laids, pour être sûr,) et ce n'est pas trop différent de la version originale.

Answer 2

Non, fondamentalement. Il est optimisé pour fournir des scénarios spécifiques/communs. Si vous sortez de ces scénarios, cela ne fonctionnera pas. Si vous avez besoin de Pulse etc, utilisez plutôt Monitor.