Colas de espera y colas en C#

Question

He tenido el siguiente código en mi aplicación durante algunos años y nunca he visto un problema.

while ((PendingOrders.Count > 0) || (WaitHandle.WaitAny(CommandEventArr) != 1)) 
{ 
    lock (PendingOrders) 
    { 
     if (PendingOrders.Count > 0) 
     { 
      fbo = PendingOrders.Dequeue(); 
     } 
     else 
     { 
      fbo = null; 
     } 
    } 

    // Do Some Work if fbo is != null 
} 

Dónde CommandEventArr se compone de la NewOrderEvent (un evento de reinicio automático) y el ExitEvent (un evento de rearme manual).

Pero no estoy seguro de si esto es seguro para subprocesos (suponiendo N hilos de productor que bloquean la cola antes de enqueing y un hilo de consumidor que ejecuta el código anterior). Además, podemos suponer que la propiedad Queue.Count simplemente devuelve un valor de Int32 de instancia de la clase Queue (sin volátil o interbloqueado o un bloqueo, etc.).

¿Cuál es el patrón habitual utilizado con una Cola y un AutoResetEvent para solucionar esto y hacer lo que estoy tratando de hacer con el código anterior?

(Modificado para cambiar la pregunta un poco después de haber sido señalado correctamente que Queue.Count podría hacer algo y su implementación específica).

Answer 1

parece bastante thr ead-safe para mí, WaitAny() simplemente se completará de inmediato porque el evento ya está configurado. Eso es no un problema.

No rompa la sincronización de subprocesos que funcione. Pero si quieres una ratonera mejor, podrías considerar la BlockingQueue de Joe Duffy en este magazine article. Una versión más general está disponible en .NET 4.0, System.Collections.Concurrent.BlockingCollection con ConcurrentQueue como una implementación práctica del mismo.

Answer 2

Sólo se debe utilizar el WaitAny para eso, y asegurarse de que se señaliza en cada nuevo pedido agregado a la colección PendingOrders:

while (WaitHandle.WaitAny(CommandEventArr) != 1)) 
{ 
    lock (PendingOrders) 
    { 
     if (PendingOrders.Count > 0) 
     { 
      fbo = PendingOrders.Dequeue(); 
     } 
     else 
     { 
      fbo = null; 

      //Only if you want to exit when there are no more PendingOrders 
      return; 
     } 
    } 

    // Do Some Work if fbo is != null 
} 

Answer 3

Usando eventos manuales ...

ManualResetEvent[] CommandEventArr = new ManualResetEvent[] { NewOrderEvent, ExitEvent }; 

while ((WaitHandle.WaitAny(CommandEventArr) != 1)) 
{ 
    lock (PendingOrders) 
    { 
     if (PendingOrders.Count > 0) 
     { 
      fbo = PendingOrders.Dequeue(); 
     } 
     else 
     { 
      fbo = null; 
      NewOrderEvent.Reset(); 
     } 
    } 
} 

Entonces es necesario asegurarse de una cerradura en el lado enqueue así:

lock (PendingOrders) 
    { 
     PendingOrders.Enqueue(obj); 
     NewOrderEvent.Set(); 
    } 

Answer 4

Usted está correcto. El código no es seguro para subprocesos. Pero no por la razón que piensas.

El AutoResetEvent está bien. Sin embargo, solo porque adquiere un bloqueo y vuelve a probar PendingOrders.Count. El quid de la cuestión es que estás llamando a PendingOrders.Count fuera de un bloqueo. Como la clase Queue no es segura para subprocesos, su código no es seguro para subprocesos ... punto.

Ahora, en realidad, probablemente nunca tenga un problema con esto por dos razones. En primer lugar, la propiedad Queue.Count está diseñada casi con certeza para nunca dejar el objeto en un estado medio cocido. Después de todo, probablemente solo devuelva una variable de instancia. En segundo lugar, la falta de una barrera de memoria en esa lectura no tendrá un impacto significativo en el contexto más amplio de su código. Lo peor que sucederá es que obtendrá una lectura obsoleta en una iteración del ciclo y luego el bloqueo adquirido creará una barrera de memoria y una nueva lectura tendrá lugar en la próxima iteración. Asumo aquí que solo hay un hilo en cola de elementos. Las cosas cambian considerablemente si hay 2 o más.

Sin embargo, permítanme dejar esto perfectamente claro. No tiene garantía de que PendingOrders.Count no altere el estado del objeto durante su ejecución. Y debido a que no está envuelto en un bloqueo, otro hilo podría iniciar una operación mientras aún se encuentre en ese estado de respaldo medio.