ThreadPool.QueueUserWorkItem con un'espressione lambda e metodo anonimo

Question

passando due parametri per un nuovo thread sul ThreadPool a volte può essere complicato, ma sembra che con le espressioni lambda e metodi anonimi, posso fare questo:

public class TestClass 
{ 
    public void DoWork(string s1, string s2) 
    { 
     Console.WriteLine(s1); 
     Console.WriteLine(s2); 
    } 
} 

try 
{ 
    TestClass test = new TestClass(); 
    string s1 = "Hello"; 
    string s2 = "World"; 
    ThreadPool.QueueUserWorkItem(
     o => test.DoWork(s1, s2) 
     ); 
} 
catch (Exception ex) 
{ 
    //exception logic 
} 

Ora, ho certamente semplificato questo esempio, ma questi punti sono fondamentali:

• Gli oggetti stringa trasmesse, sono immutabili e quindi threadsafe
• Il s1 e s2 variabili sono dichiarate w Nell'ambito del blocco try, che esco subito dopo aver accodato il lavoro al pool di thread, quindi le variabili s1 e s2 non vengono mai modificate successivamente.

C'è qualcosa di sbagliato in questo?

L'alternativa è creare una nuova classe che implementa un tipo immutabile con 3 membri: test, s1 e s2. Sembra solo un lavoro extra senza alcun beneficio a questo punto.

Answer 1

Non c'è niente di sbagliato in questo. Il compilatore sta essenzialmente facendo automaticamente ciò che hai descritto come alternativa. Crea una classe per contenere le variabili catturate (test, s1 e s2) e passa un'istanza delegata al lambda che viene trasformato in un metodo sulla classe anonima. In altre parole, se avanzi con la tua alternativa, ti ritroverai con qualcosa di molto simile a quello che il compilatore ha appena generato per te.

Answer 2

È un bel modo di farlo. Non vedo alcun svantaggio dell'uso di lambda. È semplice e pulito.

Answer 3

Per questo particolare esempio, non c'è niente di sbagliato qui. Lo stato che hai passato nell'altro thread è completamente contenuto e nessuno dei tipi coinvolge problemi di affinità di thread.

Answer 4

Quello che stai vedendo è indicato come una chiusura. Come chuckj states, il compilatore sta generando una classe in fase di compilazione che corrisponde ai membri a cui si accede al di fuori della chiusura.

L'unica cosa di cui ti devi preoccupare è se disponi di parametri di riferimento. Mentre le stringhe sono immutabili, i riferimenti a esse (o qualsiasi variabile) NON sono.

Answer 5

Un problema potenziale con il modello è che è molto allettante per espanderlo in qualcosa di più generico, ma meno sicuri come questo (zero code-non aspettatevi che funzioni):

public static void QueueTwoParameterWorkItem<T1, T2>(T1 value1, T2 value2, workDelegate<T1,T2> work) 
{ 
    try 
    { 
     T1 param1 = value1; 
     T2 param2 = value2; 
     ThreadPool.QueueUserWorkItem(
      (o) => 
      { 
       work(param1, param2); 
      }); 
    } 
    catch (Exception ex) 
    { 
     //exception logic 
    } 
}