ThreadPool.QueueUserWorkItem avec une lambda expression et de la méthode anonyme

En passant par deux paramètres à un nouveau sujet sur le pool de threads peut parfois être compliqué, mais il semble qu'avec les expressions lambda et les méthodes anonymes, je peux le faire:

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
}

Maintenant, j'ai certainement simplifié cet exemple, mais ces points sont essentiels:

  • La chaîne objets transmis sont immuables et donc des threads
  • Le s1 et s2 sont les variables déclarées à l'intérieur de la portée du bloc try, qui je le quitter immédiatement après files d'attente le travail pour le pool de threads, de sorte que le s1 et s2 les variables ne sont jamais modifiés par la suite.

Est-il quelque chose de mal avec cela?

L'alternative est de créer une nouvelle classe qui implémente une immuable type avec 3 membres: test, s1 et s2. Qui semble juste comme un travail supplémentaire sans aucun avantage à ce point.

  • Pourquoi ne pas simplement écrire o => test.DoWork(s1, s2) au lieu de la plus prolixe définition?
  • Parce que je suis vraiment nouveau dans les expressions lambda. 😉 merci!
  • Je l'ai changé à la question.
InformationsquelleAutor Scott Whitlock | 2009-04-10
  1. 16

    Il n'y a rien de mal à cela. Le compilateur est essentiellement de faire automatiquement ce que vous avez décrit comme votre alternative. Il crée une classe afin de conserver la capture de variables (test, s1 et s2) et transmet une instance de délégué pour le lambda qui est transformé en une méthode de la classe anonyme. En d'autres termes, si vous êtes allé de l'avant avec votre alternative vous vous retrouvez avec soemthing très semblable à ce que le compilateur qui vient d'être généré pour vous.

    InformationsquelleAutor chuckj
  2. 4

    Pour cet exemple particulier, non il n'y a rien de mal ici. L'état que vous avez passé dans l'autre thread est entièrement contenue et aucun des types d'impliquer toute thread problèmes d'affinité.

    • Quel est le schéma général, alors? Comment savoir si un type a thread problèmes d'affinité?
    • Fondamentalement, vous êtes en demandant si une classe est thread-safe ou pas. En mon particulier de mise en œuvre (dans la plupart des cas), je suis à l'aide de profondément des objets immuables de faire des threads. D'autres moyens de rendre les objets thread-safe est d'utiliser le verrouillage, etc.
    • si un type a thread problèmes d'affinité, vous êtes grillé. Vous ne pouvez rien faire avec elle sur un thread séparé. Le modèle général est son bien (je l'utilise souvent)
    • pas de. ThreadAffinity est très différent que de thread-safe. L'affinité de Thread signifie qu'un objet ne peut être utilisé à partir d'un thread particulier (pensez WinForms, WPF).
    • désolé, vous avez raison. Vous faites allusion à savoir si ou non la fonction DoWork tente d'accéder à un contrôle sur un formulaire, par exemple. Dans ce cas, vous devriez vérifier si une Invoke est nécessaire, et puis faire de l'Appeler si nécessaire.
    InformationsquelleAutor JaredPar
  3. 2

    C'est une belle façon de faire. Je ne vois pas les inconvénients de l'utilisation des expressions lambda. C'est simple et propre.

    InformationsquelleAutor Mehrdad Afshari
  4. 2

    Ce que vous regardez est référencé comme une fermeture. Comme chuckj unis, le compilateur génère une classe au moment de la compilation, ce qui correspond pour les membres qui sont accessibles à l'extérieur de la clôture.

    La seule chose que vous avez à vous soucier est de savoir si vous avez des ref ou des paramètres de sortie. Alors que les chaînes sont immuables, les références (ou variable) ne le sont PAS.

    InformationsquelleAutor casperOne
  5. 2

    Un problème potentiel avec le motif est que c'est très tentant de le développer en quelque chose de plus générique, mais moins fort comme ceci (code à gratter - ne vous attendez pas à du travail):

    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
    }
}
    • Dans mon cas, j'ai un profond immuable de la classe de base que je pourrais utiliser pour clouer T1 et T2... donc, vous pourriez faire ce travail dans mon cas précis. Si vous ne comprenez pas les problèmes de threading, puis en utilisant le pool de threads est hors de question de toute façon.
    • D'accord: votre cas est très bien. C'est quand vous le mettre en œuvre comme un modèle générique il ya des préoccupations.
    InformationsquelleAutor Joel Coehoorn