Code e maniglie di attesa in C#

Question

Ho avuto il seguente codice nella mia applicazione per alcuni anni e non ho mai visto un problema da esso.

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 
} 

Dove CommandEventArr è costituito dalla NewOrderEvent (un evento reset automatico) e l'ExitEvent (un evento di reset manuale).

Ma non sono sicuro se questo è thread-safe (presupponendo N thread di produzione che bloccano tutti la coda prima dell'eniviazione e un thread utente che esegue il codice sopra). Inoltre, possiamo supporre che la proprietà Queue.Count restituisca solo un valore Int32 dell'istanza dalla classe Queue (senza volatile o interbloccato o un blocco, ecc.).

Qual è il solito schema utilizzato con una coda e un AutoResetEvent per risolvere questo problema e fare ciò che sto cercando di fare con il codice sopra?

(Modificato per modificare leggermente la domanda dopo che è stato correttamente rilevato che Queue.Count poteva fare qualsiasi cosa e la sua implementazione specifica).

Answer 1

sembra abbastanza thr Per me, WaitAny() si limiterà a completare immediatamente perché l'evento è già impostato. Questo è non un problema.

Non interrompere la sincronizzazione della filettatura che funziona. Ma se vuoi una trappola per topi migliore allora potresti considerare BlockingQueue di Joe Duffy in questo magazine article. Una versione più generale di esso è disponibile in .NET 4.0, System.Collections.Concurrent.BlockingCollection con ConcurrentQueue come implementazione pratica di esso.

Answer 2

Si dovrebbe utilizzare solo il WaitAny per questo, e garantire che venga segnalato su ogni nuovo ordine aggiunto alla collezione 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

Utilizzando eventi manuali ...

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(); 
     } 
    } 
} 

Poi è necessario garantire un blocco sul lato Enqueue così:

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

Answer 4

Sei corretto. Il codice non è thread-safe. Ma non per la ragione che pensi.

AutoResetEvent va bene. Tuttavia, solo perché acquisisci un blocco e riesegui il test di PendingOrders.Count. Il vero nodo della questione è che stai chiamando PendingOrders.Count al di fuori di un lucchetto. Poiché la classe Queue non è thread-safe, il tuo codice non è thread-safe ... period.

Ora in realtà probabilmente non avrai mai un problema con questo per due motivi. Innanzitutto, la proprietà Queue.Count è quasi certamente progettata per non lasciare mai l'oggetto in uno stato semi-cotto. Dopotutto, probabilmente restituirà solo una variabile di istanza. In secondo luogo, la mancanza di una barriera di memoria su quella lettura non avrà un impatto significativo nel più ampio contesto del tuo codice. La cosa peggiore che accadrà è che si otterrà una lettura stantio su un'iterazione del ciclo e quindi il blocco acquisito implicherà la creazione di una barriera di memoria e una nuova lettura avrà luogo alla successiva iterazione. Presumo qui che ci sia un solo elemento di accodamento del thread. Le cose cambiano considerevolmente se ci sono 2 o più.

Tuttavia, vorrei chiarirlo perfettamente. Non si ha garanzia che PendingOrders.Count non modificherà lo stato dell'oggetto durante la sua esecuzione. E poiché non è racchiuso in un blocco, un altro thread potrebbe iniziare un'operazione su di esso mentre è ancora in quello stato a metà schiena.