ThreadPool.QueueUserWorkItem con una expresión lambda y método anónimo

Question

Al pasar dos parámetros para un nuevo hilo en el conjunto de subprocesos a veces puede ser complicado, pero parece que con las expresiones lambda y métodos anónimos, que puedo hacer esto:

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
}

Ahora, ciertamente he simplificado este ejemplo, pero estos puntos son claves:

• Los objetos de cadena que se transmiten son inmutables y por lo tanto para las hebras
• Las variables S1 y S2 se declaran dentro del ámbito del bloque try, que salgo inmediatamente después de hacer cola para el trabajo del grupo de subprocesos, por lo que las variables S1 y S2 no se modifican después de eso.

¿Hay algo malo en esto?

La alternativa es crear una nueva clase que implementa un tipo inmutable con 3 miembros: prueba, S1, y S2. Eso sólo parece como trabajo extra sin ningún beneficio en este punto.

Answer 1

No hay nada malo con esto. El compilador está haciendo esencialmente de forma automática lo que usted describe como su alternativa. Se crea una clase para mantener las variables capturados (prueba, S1 y S2) y pasa a una instancia de delegado a la lambda que se convierte en un método en la clase anónima. En otras palabras, si usted siguió adelante con su alternativa que acabaría con soemthing muy similar a lo que el compilador genera solo para ti.

Answer 2

En este ejemplo en particular, no hay nada malo aquí. El estado que haya pasado en el otro hilo está contenida wholely y ninguno de los tipos involucrar a tener ningún problema de afinidad hilo.

Answer 3

Es una buena manera de hacerlo. No veo ninguna desventaja del uso de lambdas. Es muy sencillo y limpio.

Answer 4

Lo que se está viendo es referido como un cierre. Como chuckj estados , el compilador está generando una clase en tiempo de compilación que corresponde a los miembros que se accede exterior del cierre.

Lo único que tiene que preocuparse es si tiene o ref parámetros out. Mientras que las cadenas son inmutables, las referencias a ellos (o cualquier variable) no lo son.

Answer 5

Un problema potencial con el patrón es que es muy tentador para expandirlo en algo más genérico, pero menos seguro como esto (código- cero no esperar que funcione):

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
    }
}