Presque toute la documentation que j'ai vue sur l'utilisation de la tâche C # 4.0.Factory.StartNew indique que pour attendre la tâche de terminer, vous avez besoin d'une attente. Mais mes tests initiaux montrent qu'il est inutile. Quelqu'un d'autre peut-il me donner une confirmation à ce sujet? Je suis curieux de savoir pourquoi tant de références en ligne et imprimées disent que vous devriez appeler WAIT.
Voici une simple application de console qui montre que je n'ai pas besoin de la déclaration d'attente, alors je l'ai commencée. Je commente si ou non le Tsk.wait (), la sortie est la même. P>
Sortie attendue Dans tous les cas est la suivante: P>
class Program { // A trivial method that returns a result and takes no arguments. static bool MyTask() { Thread.Sleep(2000); return true; } // This method returns the summation of a positive integer // which is passed to it. static int SumIt(object v) { int x = (int)v; int sum = 0; for (; x > 0; x--) sum += x; return sum; } static void Main(string[] args) { Console.WriteLine("Main thread starting."); // Construct the first task. Task<bool> tsk = Task<bool>.Factory.StartNew(() => MyTask()); // I found this Wait statement to be completely unnecessary. //tsk.Wait(); Console.WriteLine("After running MyTask. The result is " + tsk.Result); // Construct the second task. Task<int> tsk2 = Task<int>.Factory.StartNew(() => SumIt(1)); Console.WriteLine("After running SumIt. The result is " + tsk2.Result); tsk.Dispose(); tsk2.Dispose(); Console.WriteLine("Main thread ending."); Console.ReadLine(); } }
4 Réponses :
Etant donné selon Ce , accédant à la valeur < / code> de la tâche code> code> garantit que la tâche est terminée, vous avez raison que ce n'est pas nécessaire. P>
C'est correct. Merci, Jacob! Mon erreur était que j'ai oublié que j'utilisais la tâche
Si vous voulez juste attendre la tâche à terminer, le plan d'action recommandé est d'appeler pour une tâche .wait () code>. Pour une tâche
code> (par opposition à une tâche
.result code>, lequel aussi em> attend, et c'est ce que vous utilisez. . Donc, dans votre cas, il n'est pas nécessaire d'appeler
.wait () code>. P>
Merci, timwi. J'ai eu un pet de cerveau et je n'ai pas remarqué que j'avais l'aide de la tâche
Comme Timwi a déclaré, .Result attend également. Puisque vous utilisez TSK.RESULT dans votre console.writeline Appel, vous faites l'attente comme effet secondaire. p>
Cela dépend aussi de la durée de la tâche de remplir. Si cela est très court, vous ne réalisez peut-être pas la nécessité de. Appoute, car il semble toujours finir à temps. Il y a danger de le laisser si vous avez besoin de la tâche à compléter avant de continuer. Le .wait devrait donc être utilisé même si 99% du temps, il n'entraîne pas vraiment de temps à attendre. P>
une caractéristique importante de *) Apparemment, cela sera changé. Le comportement est modifié dans l'ASYNC CTP. p> attendre code> est-il intégré comme un point de rendez-vous en ce que toute exception projetée par la tâche
code> sera à nouveau à ce point. Étant donné que la tâche code> actuelle code> * vous oblige à observer une telle exception
wait code> est une bonne option pour le faire. Vous pouvez toutefois observer également l'exception en interrogeant la tâche code> code> d'une exception. p>