Le operazioni di linq su raccolte simultanee thread safe?

Question

Per esempio è il seguente thread-safe codice:

ConcurrentQueue<Guid> _queue = new ConcurrentQueue<Guid>(); 
     while(true) 
     { 
      for(int y = 0; y < 3; y++) 
      { 
       if(y % 3 == 0) 
       { 
        System.Threading.Tasks.Task.Run(() => _queue.Enqueue(Guid.NewGuid())); 
       } 
       else if (y % 3 == 1) 
       { 
        Guid x; 
        System.Threading.Tasks.Task.Run(() => _queue.TryDequeue(out x)); 
       } 
       else if(y % 3 == 2) 
       { 
        System.Threading.Tasks.Task.Run(() => 
        { 
         if (_queue.Any(t => t == testGuid)) 
         { 
          // Do something 
         } 
        }); 

       } 
      } 

Edit: A quanto pare il titolo non era abbastanza chiaro in modo aggiornato il codice di esempio per includere effettivo comportamento più threaded, sì, il codice di cui sopra è solo un campione di di comportamento multithread.

Answer 1

Le operazioni LINQ sono di sola lettura, quindi sono filettate su tutte le raccolte. Ovviamente, se aggiungi un codice che modifica una collezione all'interno del metodo Where o Select, cessano di essere thread-safe.

Raccolte thread-safe assicurano che le modifiche siano thread-safe, il che non è davvero un problema quando si esegue una query LINQ.

Cosa non è sicuro sta modificando una raccolta durante l'attraversamento. Le raccolte normali invalidano gli iteratori quando vengono modificati, mentre le raccolte thread-safe no. In alcuni casi, ad esempio in ConcurrentQueue, ciò viene ottenuto presentando un'istantanea dei dati durante l'iterazione.

Answer 2

Sì, secondo documentation

Il namespace System.Collections.Concurrent fornisce diverse classi collezione thread-safe che devono essere utilizzati al posto dei tipi corrispondenti nelle System.Collections e sistema. Collections.Gli spazi dei nomi generici ogni volta che più thread sono che accede alla raccolta contemporaneamente.

Answer 3

Sì, ma ...

Prendiamo il tuo esempio:

if(_queue.Any(t => t == testGuid)) 
{ 
    // Do something 
} 

Ora questo non sarà, non importa ciò che altri thread stanno facendo, riuscire con un'eccezione se non in modi documentati (che in questo caso significa fallire con qualsiasi eccezione), inserire _queue in uno stato non valido o restituire una risposta errata.

È, come tale, thread-safe.

E adesso?

Il codice a // Do something è presumibilmente da eseguire solo se c'è un elemento nella coda che corrisponde a testGuid. Sfortunatamente non sappiamo se questo è vero o no, perché il flusso di tempo di Heraclitan è andato avanti, e tutto quello che sappiamo è che lì è stato un tale Guid di.

Ora, questo non è necessariamente inutile. Ad esempio, potremmo sapere che la coda è attualmente aggiunta solo a (forse il thread corrente è l'unico che si deseleziona ad esempio, o che tutte le operazioni di dequeue avvengono in determinate condizioni che sappiamo che non sono a posto). Allora sappiamo che c'è ancora un tale guid lì. O potremmo semplicemente voler segnalare che testGuid è stato visto se è ancora lì o no.

Ma se // Do something dipende dalla presenza di testGuid nella coda e la coda viene rimossa dalla coda, il blocco di codice nel suo complesso non è thread-safe, sebbene l'espressione di collegamento sia.