En attente de plusieurs Tâches avec des résultats différents

J'ai 3 tâches:

private async Task<Cat> FeedCat() {}
private async Task<House> SellHouse() {}
private async Task<Tesla> BuyCar() {}

Ils ont tous besoin de courir avant de mon code peut continuer et j'ai besoin des résultats de chacun ainsi. Aucun de ces résultats n'ont rien en commun les uns avec les autres

Comment dois-je appeler et d'attendre pour les 3 tâches à accomplir et ensuite obtenir les résultats?

Avez-vous de la commande exigence? C'est, ne vous en veux pas vendre la maison jusqu'à ce que après le chat est-il nourri?

InformationsquelleAutor BahaiResearch.com | 2013-06-19

315

Après l'utilisation de WhenAll, vous pouvez tirer sur les résultats individuellement avec await:
```
var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

var cat = await catTask;
var house = await houseTask;
var car = await carTask;
```
Vous pouvez également utiliser Task.Result (puisque vous savez en ce moment, ils ont tous terminé avec succès). Cependant, je vous recommande d'utiliser await parce que c'est clairement juste, tout en Result peut causer des problèmes dans d'autres scénarios.
- Vous pouvez simplement supprimer le WhenAll à partir de ce entièrement; l'attend va prendre soin de vous assurant de ne pas dépasser les 3 plus tard affectations jusqu'à ce que les tâches sont toutes terminées.
- Vrai, si WhenAll a une intention explicite.
- Je suis un peu perdu ici. Je reçois le même comportement avec ou sans le WhenAll et même si je le remplace par un WhenAny.
- Pour le WhenAny cas j'ai été absent un si IsCompleted pour chaque tâche. L'utilisation de la cascade, en attend est source de confusion. Lorsque le Résultat serait un échec? Dans le cas d'une exception?
- Dans le cas d'un reproché à la tâche, Result clôturera l'exception d'origine à l'intérieur d'un AggregateException, ce qui complique la gestion des erreurs.
- Task.WhenAll() permet d'exécuter la tâche dans parallèle mode. Je ne comprends pas pourquoi @Servy a suggéré de le supprimer. Sans le WhenAll ils seront exécutés un par un
- Les tâches d'exécution commence immédiatement. E. g., catTask est déjà en cours d'exécution par le temps, il est retourné à partir de FeedCat. Donc, soit l'approche de travail - la seule question est de savoir si vous voulez await un par un ou tous ensemble. L'erreur de manipulation est légèrement différente - si vous utilisez Task.WhenAll, alors il sera await tous, même si l'un d'eux ne parvient pas au début.
- L'appel de WhenAll n'a pas d'incidence sur le moment où les activités d'exécuter ou de la façon dont ils exécutent. que a toute permet s'effectuer de la façon dont les résultats sont observés. Dans ce cas particulier, la seule différence est qu'une erreur dans l'une des deux premières méthodes entraînerait l'exception levée dans cette pile d'appel plus tôt dans ma méthode de Stephen (bien que la même erreur serait de toujours être levée, si il y en a).
- d'accord avec vous. Je voulais mentionner que si vous avez 3 missions pour les 3, 4 et 5 secondes respectivement WhenAll travaillera en 5 secondes. D'autre part les exécuter EN CHAÎNE pour l'3+4+5=12 secondes. Comme quelqu'un a dit: les tâches ne doivent pas être liés les uns aux autres pour la WhenAll. C'est pourquoi je pense WhenAll a une influence majeure de la performance par exemple.
- lire mon commentaire précédent. En cours d'exécution "par la chaîne" et en cours d'exécution "en parallèle" mode sont complètement différents. Dans le WhenAll elles sont exécutées IMMÉDIATEMENT. Sans elle, ils sont exécutés une fois que le précédent. await; + await; == await.ContinueWith(await;);
- Il ne serait que de 12 secondes si vous attendu de chacun avant d'appeler la méthode suivante. Si vous structurez le code comme Servy de réponse, il ne serait que de 5 secondes.
- Aller de l'avant et fait exécuter le code pour vous-même et l'heure si vous ne croyez pas que Stephen. Vous n'avez pas à prendre notre mot pour lui.
- J'ai été tordre les gars, désolé. Je ne pouvais pas imaginer qu'une telle syntaxe pourrait être la parallèle. Absolument confus pour moi
- La clé est que les méthodes asynchrones toujours le retour "à chaud" (déjà commencé) des tâches.
- Pouvez-vous expliquer pourquoi nous avons besoin d'un autre attendent au lieu de tirer directement le résultat? Aussi quelle est la meilleure approche à l'aide de la Tâche.WhenAll ou tout simplement en attente d'eux, tel que mentionné par @Servy?
- Stephen et j'ai déjà couvert les très légères différences entre les deux options dans ce même fil de commentaires. Si l'un de ces différences sont utiles pour vous, puis choisissez en conséquence. Si aucune de ces différences de matière dans votre situation (ce qui est le plus comme option) il est tout simplement une question de préférence personnelle.
- est droit, whenAll est en cours d'exécution en parallèle, vous attendent dans la chaîne est en attente, un par un. Le temps d'exécution dit la vérité.
- Je voudrais ajouter .ConfigureAwait(false) à la WhenAll(tasks) appel à garder à partir de blocage du thread. Ce serait la manière la plus optimale pour exécuter cette parallélisation.
- À l'aide de l'attendent Tâche.WhenAll, si FeedCat tâches de 10 secondes, SellHouse 3 secondes et BuyCar 2 secondes, une fois SellHouse et BuyCar sont faites, sont ces 2 Tâches libéré en attendant FeedCat ou c'est seulement le "principal" thread qui est libéré lors de l'attente pour les 3 Tâches à faire?
- Je ne suis pas sûr de ce que vous entendez par "libéré". Ces tâches sont terminées, si c'est ce que tu veux dire.
- Cleary Libéré et de retour pour le pool de threads afin qu'ils puissent répondre à la nouvelle demande. Parce que si l'un des 3 Tâches prendre beaucoup plus de temps que les 2 autres, je déchets 2 thread en attente de la troisième à terminer ?
- Ces tâches ne sont pas les threads. Ils sont la Promesse de Tâches, pas de Déléguer des Tâches. Il est donc inutile de les prendre dans le pool de threads en premier lieu.
- Est-il possible d'écrire un code vous permettant de procéder selon l'une renvoie en premier?
- Vous pouvez utiliser Task.WhenAny.
- ou quelqu'un d'autre avec cette question, voir: docs.microsoft.com/en-us/dotnet/csharp/programming-guide/...
- Voici un exemple qui prouve Task.WhenAll n'est pas nécessaire. gist.github.com/aherrick/239647bf24bd6483924ce6a22f5c8edf
- La droite. Comme je l'explique ci-dessus, le traitement des erreurs est un peu différent sans WhenAll. Mais la raison principale que j'en général, il est de sorte que le code est claire. Il est plus facile pour quelqu'un de familier avec elle pour comprendre l'intention et de la sémantique de la méthode, et donc le code est plus facile à maintenir.
- WhenAll est utile quand on a des tâches créées dans la boucle foreach
- Si vous l'avez explicitement appel await Task.WhenAll(catTask, houseTask, carTask);, ne serait-il pas un meilleur choix que d'appeler catTask.Result plutôt qu'une trompeuse await? @StephenCleary, ne serait pas une exception, comme vous le mentionnez, être levée lorsque la .WhenAll complète et donc il n'y a pas de mal à l'aide de .Wait après await Task.WhenAll?
- Le Code à l'aide await est plus résistant à la refactorisation, car il ne peut pas accidentellement devenu le blocage de code. Permettez-moi de renverser votre question. Étant donné que await est le naturel moyen de la consommation d'une tâche, quels sont les avantages d' Result/Wait ont le plus naturel await?
- Quand je vois un await, je suppose qu'il est nécessaire d'attendre un peut-être-tâche inachevée de retour. Dans notre cas, l'attente est déjà passé sur le .WhenAll ligne, de sorte que le résultat est garanti d'être là, de façon synchrone. (Vous ne pouvez pas appeler .Wait, seulement .Result; veuillez pardonner ma faute de frappe.)
- de la tâche.Le résultat est un fil bloquant. Ne pas le faire.
InformationsquelleAutor Stephen Cleary
74

Juste await les trois tâches séparément, après le démarrage de tous.
```
var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

var cat = await catTask;
var house = await houseTask;
var car = await carTask;
```
- Non, c'est faux. Ils vont faire leur travail en parallèle. Se sentir libres de les utiliser et voir par vous-même.
- Personnes continuez à poser la même question après des années... je pense qu'il est important de souligner encore une fois qu'un groupe de "commence à créer" dans le corps de la répondre: peut-être qu'ils ne pas la peine de lire les commentaires
- Il n'y a qu'une seule phrase dans la réponse, et il dit déjà que...
- il ne dit pas cela du tout. Il est dit "Juste attendre les trois tâches séparément, après le démarrage de tous." Il n'est pas explicitement dire que "la création de la tâche démarre".
- Le code de cette réponse NE retour au .Résultat et chaque tâche est attendu un par un. Pour les exécuter simultanément et faire le plus de l'avantage de "asynchrone" programmation alors il est préférable d'utiliser de la Tâche.WhenAll(catTask, houseTask, carTask) puis d'appeler les résultats par le biais de l' .Résultat de propriété sur chacun d'eux. Cela permettra d'assurer le plus possible le moment de l'exécution pour remplir toutes les opérations.
- L'ajout de Task.WhenAll changements littéralement rien sur le comportement du programme, dans toutes les observables façon. C'est un purement redondant appel de méthode. Vous êtes invités à ajouter, si vous le souhaitez, comme un choix esthétique, mais il ne change pas ce que fait le code. Le temps d'exécution du code est identique avec ou sans cet appel de méthode (enfin, techniquement, il y a un vraiment petit de frais généraux pour les appelant WhenAll, mais cela devrait être négligeable), ne faisant que de la version un peu plus de temps que cette version.
- La façon la plus simple de voir qui consiste simplement à écrire un exemple de programme et de voir ce qui se passe réellement lorsque vous l'exécutez, avec et sans le WhenAll en elle. Qui vous permettra de voir par vous-même ce qui l'exécute et quand.
- Je n'ai fait de prendre le temps d'écrire une application de test avant de poster ici, et les résultats montrent que vous êtes en fait incorrect. Exécuter mon code (dans une réponse distincte sur la question) et vous pouvez voir le point de l'être démontrée. J'ai trois méthodes, la première dormir pendant 5 secondes, puis un autre pendant 1 seconde et l'autre pour 3 secondes. Exécution comme vous le suggérez, en attente de chacun, le temps d'exécution est de 9 secondes. Vous êtes ademant que l'utilisation de WhenAll(un, deux, trois) n'a absolument aucune différence et c'est juste du sucre syntaxique, mais en fait le temps d'exécution est de 5 secondes. Vous êtes dans l'erreur.
- Votre exemple exécute les opérations successivement pour deux raisons. Vos méthodes asynchrones ne sont pas réellement asynchrone, ils sont synchrones. Le fait que vous avez synchrone des méthodes qui retournent toujours déjà terminé les tâches qui les empêche de s'exécuter simultanément. Ensuite, vous n'avez pas vraiment faire ce qui est indiqué dans cette réponse de partir tous les trois méthodes asynchrones, et puis en attendant les trois tâches à tour de rôle. Votre exemple ne pas faire appel chaque méthode jusqu'à ce que la précédente a fini, donc explicitement la prévention de l'une de démarrer jusqu'à ce que la précédente a fini, à la différence de ce code.
- Puisque vous avez besoin d'une mise en œuvre de FeedCat, SellHouse et BuyCar être fourni pour tester le code, vous pouvez l'utiliser pour chacun d'eux : Task FeedCat(){return Task.Delay(1000);}Task SellHouse(){return Task.Delay(1000);}Task BuyCar(){return Task.Delay(1000);}. Vous pouvez utiliser ces méthodes pour les tests, et ensuite il suffit de copier-coller le code de la réponse dans une méthode et l'exécuter pour voir courir en 1 seconde, au lieu de 3.
- Vous voyez qu'en fait un peu aidé. Un commentaire précédent vous a dit d'utiliser return Task.Delay... qui je pensais était faux, parce que je ne pourrait le faire avec await Task.Delay.... Maintenant, je sais que vous voulait PAS la marque de la méthode asynchrone. De toute façon, cette discussion, c'est un gaspillage d'énergie à partir de ce point. Merci pour votre temps
- Je suis heureux que vous étiez en mesure d'exécuter l'exemple et obtenir le résultat attendu de cette information, et que vous comprenez maintenant que la WhenAll est tout simplement inutile pour résoudre ce problème à l'aide de votre travail maintenant des méthodes asynchrones.
- Vous avez fait clair jusqu'à un point dans l'exemple, mais il y avait encore un grand trou béant à la pourquoi. J'ai eu une longue discussion avec un collègue qui a fourni très clairement la raison du "pourquoi" de ces exécutent simultanément et encore, bloque sur la dernière attendent déclaration. Il y a une plus grande image autour async / await quand il s'agit de l'utilisation dans un projet exécutable vs hébergés dans IIS, qui m'a aidé. J'avoue que c'est au-delà de la portée de ce que cette SORTE de post est sur, mais je maintiens qu'il serait utile de vous expliquer en détail au début plutôt votre approche dans ce fil.
- Il n'y a rien d'intrinsèquement différentes sur la façon await travaille dans un fichier exécutable vs une application IIS. Quelle différence faites-vous pensez qu'il est pertinent? Bien sûr, cette réponse n'est pas conçu pour être un tutoriel qui couvre tous les éléments de base de la TPL. Ce n'est pas seulement au-delà de la portée de cette question spécifique, il est aussi au-delà de la portée de ce qui peut vraiment être fournies dans aucun donné de réponse. Cela dit, si vous avez une question plus spécifique quant à pourquoi, ni comment ce code fonctionne, puis par tous les moyens, posez-vous la question, et je vais faire de mon mieux pour répondre à votre question.
- bien sûr, cette réponse n'est pas conçu pour être un tutoriel qui couvre tous les éléments de base de la TPL" ...alors pourquoi êtes-vous de continuer la conversation entre eux? Voyant que vous avez il y a une différence à faire avec si vous allez utiliser asynchrone il est alors nécessaire (plus souhaitable) de faire tous les appels dans l'chiang async long de blocage d'appels ne peuvent pas être mis en sommeil par IIS et ramené lorsqu'une réponse est finalement reçu afin de libérer le thread principal, quelque chose n'est pas un problème lors de l'exécution de la vanille, de l'application bureau. Mais fonctionnellement, dans son usage, il est identique. De toute façon, s'il vous plaît arrêter d'y répondre.
- Downvoted parce que: dans votre exemple, les tâches s'exécutent à tour de rôle.HouseTask commence lorsque CatTask est fini. En utilisant WhenAll, toutes les tâches s'exécutent en parallèle et sont tous fait lorsque vous obtenez la valeur à l'aide de l'attendent.
- C'est manifestement pas vrai, comme il a été dit dans les commentaires ici, et sur d'autres réponses. L'ajout de WhenAll est purement un changement esthétique. La seule différence observable dans le comportement est de savoir si vous attendre pour plus tard les tâches de finition, si une tâche antérieure défauts, ce qui n'est généralement pas nécessaire de le faire. Si vous ne croyez pas les nombreuses explications pourquoi votre déclaration n'est pas vrai, vous pouvez simplement exécuter le code, vous verrez que ce n'est pas vrai.
- Désolé. Je n'ai pas regardé l'exemple vraiment bien. J'ai manqué que vous avez commencé les tâches en premier et ensuite les attendent. Vous êtes correct. Je ne peux pas éditer mon downvote plus. Il est verrouillé. Mais vous êtes tout à fait correct.
InformationsquelleAutor Servy
29

Si vous êtes à l'aide de C# 7, vous pouvez utiliser une pratique wrapper méthode comme ceci...
```
public static class TaskEx
{
    public static async Task<(T1, T2)> WhenAll<T1, T2>(Task<T1> task1, Task<T2> task2)
    {
        await Task.WhenAll(task1, task2);
        return (task1.Result, task2.Result);
    }
}
```
...pour permettre la pratique de la syntaxe comme ça quand vous voulez attendre sur des tâches multiples avec différents types de retour. Vous auriez à faire plusieurs surcharges pour différents nombres de tâches d'attendre, bien sûr.
```
var (someInt, someString) = await TaskEx.WhenAll(GetIntAsync(), GetStringAsync());
```
- Je ne trouve pas cette fonction dans la version finale...
- Les Tuples sont les seuls C# 7 de la fonctionnalité en cause ici. Ceux-ci sont certainement dans la version finale.
- Je sais que sur les tuples et c# 7. Je veux dire que je ne peux pas trouver la méthode la WhenAll qui le retour des n-uplets. Quel espace de noms/paquet?
- n'est-ce pas le retour d'un n-uplet. On est en train d'être construit à partir de la Result propriétés de la condition des tâches après la tâche retourné par Task.WhenAll() complète.
- Je te suggère de remplacer le .Result appels par Stephen raisonnement d'éviter d'autres personnes de perpétuer la mauvaise pratique par la copie de votre exemple.
InformationsquelleAutor Joel Mueller
11

Vous pouvez les stocker dans des tâches, puis attendent tous:
```
var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

Cat cat = await catTask;
House house = await houseTask;
Car car = await carTask;
```
- ne pas var catTask = FeedCat() exécuter la fonction FeedCat() et stocker le résultat dans catTask faire la await Task.WhenAll() partie plutôt inutile, puisque la méthode a déjà été exécutée ??
- si ils reviennent tâche <t>, puis non... ils commencent à l'async ouvert, mais n'attendez pas qu'il
- Je ne pense pas que ce soit exact, veuillez consulter les discussions en vertu de l' @StephenCleary de réponse... voir aussi Servy de réponse.
- si je dois ajouter .ConfigrtueAwait(false). J'ajoute qu'il suffit de la Tâche.WhenAll ou à chaque awaiter qui suit?
- en général, c'est une bonne idée de l'ajouter à tous (si le premier est terminé, il obtient effectivement ignoré), mais dans ce cas, il serait probablement bon de faire de la première - à moins qu'il n'y a plus async choses qui se sont produites plus tard.
- Non, il n'est pas inutile. Si la tâche a déjà terminé alors oui, il ne fera aucune différence, mais si ce sont des tâches longues, alors cela signifie que, pour chaque tâche s'exécute en même temps et rien ne poursuit ensuite whenall jusqu'à ce que chaque tâche a terminé...accordée même si une tâche PEUT se terminer immédiatement
- Selon les commentaires de stackoverflow.com/a/17197745/2305386 la await Task.WhenAll n'est pas nécessaire ici, les trois tâches commencé et après qui l'attendait, ensemble, vont se dérouler en parallèle.
- Ils vont s'exécuter en parallèle sans WhenAll, vous pouvez obtenir le Chat résultat avant de la maison est fait, etc (ce qui peut ou peut ne pas être important).
InformationsquelleAutor Reed Copsey
10

Donné trois tâches - FeedCat(), SellHouse() et BuyCar(), il y a deux cas: soit qu'elles aient terminé de façon synchrone (pour une raison quelconque, peut-être la mise en cache ou d'une erreur), soit ils ne le sont pas.

Disons que nous avons, à partir de la question:
```
Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();
    //what here?
}
```
Maintenant, une approche simple serait:
```
Task.WhenAll(x, y, z);
```
mais ... qui n'est pas commode pour le traitement des résultats, nous serions souhaitez généralement await que:
```
async Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    await Task.WhenAll(x, y, z);
    //presumably we want to do something with the results...
    return DoWhatever(x.Result, y.Result, z.Result);
}
```
mais cela fait beaucoup de frais généraux et alloue les différents tableaux (y compris les params Task[] tableau) et les listes (en interne). Cela fonctionne, mais il n'est pas exceptionnel de l'OMI. Dans beaucoup de façons, il est plus simple d'utiliser un async fonctionnement et juste await chacun à leur tour:
```
async Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    //do something with the results...
    return DoWhatever(await x, await y, await z);
}
```
Contrairement à certains commentaires ci-dessus, à l'aide de await au lieu de Task.WhenAll fait pas de différence à la façon dont les tâches s'exécutent (simultanément, de manière séquentielle, etc). Au plus haut niveau, Task.WhenAll est antérieure à bonne prise en charge du compilateur pour async/await, et a été utile lorsque ces choses n'existent pas. Il est également utile lorsque vous avez l'arbitraire d'un tableau de tâches, plutôt que 3 discrètes tâches.

Mais: nous avons toujours le problème que async/await génère beaucoup de compilateur de bruit pour la suite. Si il est probable que les tâches pourrait de terminer de façon synchrone, alors nous pouvons optimiser ce, en s'appuyant dans un synchrones chemin d'accès avec un asynchrone de secours:
```
Task<string> DoTheThings() {
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    if(x.Status == TaskStatus.RanToCompletion &&
       y.Status == TaskStatus.RanToCompletion &&
       z.Status == TaskStatus.RanToCompletion)
        return Task.FromResult(
          DoWhatever(a.Result, b.Result, c.Result));
       //we can safely access .Result, as they are known
       //to be ran-to-completion

    return Awaited(x, y, z);
}

async Task Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
    return DoWhatever(await x, await y, await z);
}
```
Cette "synchronisation de chemin avec async de secours" de l'approche est de plus en plus fréquent en particulier dans la haute performance code où synchrone les achèvements sont relativement fréquentes. Remarque il ne va pas aider du tout si la fin est toujours véritablement asynchrone.

Choses supplémentaires qui s'appliquent ici:
1. avec les récentes C#, un modèle commun est la async de secours méthode est couramment mis en œuvre comme une fonction locale:
```
Task<string> DoTheThings() {
    async Task<string> Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
        return DoWhatever(await a, await b, await c);
    }
    Task<Cat> x = FeedCat();
    Task<House> y = SellHouse();
    Task<Tesla> z = BuyCar();

    if(x.Status == TaskStatus.RanToCompletion &&
       y.Status == TaskStatus.RanToCompletion &&
       z.Status == TaskStatus.RanToCompletion)
        return Task.FromResult(
          DoWhatever(a.Result, b.Result, c.Result));
       //we can safely access .Result, as they are known
       //to be ran-to-completion

    return Awaited(x, y, z);
}
```
2. préfèrent ValueTask<T> à Task<T> si il y a une bonne chance de choses jamais complètement de façon synchrone avec différentes valeurs de retour:
```
ValueTask<string> DoTheThings() {
    async ValueTask<string> Awaited(ValueTask<Cat> a, Task<House> b, Task<Tesla> c) {
        return DoWhatever(await a, await b, await c);
    }
    ValueTask<Cat> x = FeedCat();
    ValueTask<House> y = SellHouse();
    ValueTask<Tesla> z = BuyCar();

    if(x.IsCompletedSuccessfully &&
       y.IsCompletedSuccessfully &&
       z.IsCompletedSuccessfully)
        return new ValueTask<string>(
          DoWhatever(a.Result, b.Result, c.Result));
       //we can safely access .Result, as they are known
       //to be ran-to-completion

    return Awaited(x, y, z);
}
```
3. si possible, préférez IsCompletedSuccessfully à Status == TaskStatus.RanToCompletion; ce qui existe maintenant dans .NET de Base pour Task, et partout pour ValueTask<T>
- "Contrairement à diverses réponses ici, en utilisant attendent au lieu de la Tâche.WhenAll ne fait aucune différence à la façon dont les tâches s'exécutent (simultanément, de manière séquentielle, etc)" je ne vois pas la réponse que dire que. J'avais déjà commenté leur disant que si ils l'ont fait. Il y a beaucoup de commentaires sur un grand nombre de réponses en disant ça, mais pas de réponses. Qui faites-vous allusion? Notez également que votre réponse ne gère pas le résultat des tâches (ou de composer avec le fait que les résultats sont tous de type différent). Vous avez composé dans une méthode qui retourne un Task quand ils sont tous fait sans l'aide des résultats.
- vous avez raison, c'était les commentaires; je vais ajouter un tweak pour montrer à l'aide des résultats
- tweak ajouté
- Aussi, si vous allez prendre le début de la transmission synchrone des tâches, vous pouvez ainsi gérer toutes les tâches de manière synchrone être annulé ou les erreurs, pas seulement celles qui ont terminé avec succès. Si vous avez pris la décision que c'est une optimisation de votre programme a besoin (ce qui est rare, mais qui va arriver), alors vous pourriez aussi bien aller tout le chemin.
- c'est un sujet complexe - vous obtenir différents exception de la sémantique des deux scénarios en attente pour déclencher une exception se comporte différemment de l'accès .Résultat pour le déclenchement de l'exception. L'OMI à ce point, nous devons nous await pour obtenir le "mieux" exception de la sémantique, sur l'hypothèse que les exceptions sont rares mais significatifs
- En effet vous ne voudriez pas appel Result laisser lever des exceptions comme il n'est pas souhaitable de la sémantique. Vous auriez besoin d'utiliser Task.FromException pour construire le bon résultat. Il serait plus de travail (bien que le travail que vous pourriez tout simplement écrire une fois et le bâton dans une méthode, donc pas de que beaucoup plus de travail), mais je suppose que quelqu'un qui ne peut pas se permettre de prendre le temps de créer un objet si les tâches sont tous terminés veut l'éviter, même lorsque certains sont défectueuses ou de l'annulation.
InformationsquelleAutor Marc Gravell

Dans le cas où vous essayez de vous connecter à toutes les erreurs, assurez-vous garder Tâche.WhenAll ligne dans votre code, beaucoup de commentaires suggèrent que vous pouvez le retirer et d'attendre pour des tâches individuelles. De la tâche.WhenAll est vraiment important pour la gestion des erreurs. Sans cette ligne, vous laissant potentiellement votre code ouvert pour non des exceptions.

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

await Task.WhenAll(catTask, houseTask, carTask);

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

Imaginer FeedCat throws exception dans le code suivant:

var catTask = FeedCat();
var houseTask = SellHouse();
var carTask = BuyCar();

var cat = await catTask;
var house = await houseTask;
var car = await carTask;

Dans ce cas, vous ne serez jamais vous attendent sur houseTask ni carTask. Il y a 3 scénarios possibles ici:

SellHouse est déjà terminée lorsque FeedCat a échoué. Dans
ce cas, vous êtes beaux.
SellHouse n'est pas complète et ne parvient pas, sauf exception, à un certain point. Exception n'est pas observée et seront relancés sur finaliseur fil.
SellHouse n'est pas complète et contient attend à l'intérieur. En cas
votre code s'exécute dans ASP.NET SellHouse échouent dès que certains de la
attend sera complété à l'intérieur. Cela se produit parce que vous avez
fait feu & oubliez pas d'appeler et de contexte de synchronisation a été perdu dès que FeedCat échoué.

Voici l'erreur que vous obtenez pour le cas (3):

System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean setImpersonationContext)
   at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean setImpersonationContext)
   at System.Web.HttpApplication.System.Web.Util.ISyncContext.Enter()
   at System.Web.Util.SynchronizationHelper.SafeWrapCallback(Action action)
   at System.Threading.Tasks.Task.Execute()
   --- End of inner exception stack trace ---
---> (Inner Exception #0) System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean setImpersonationContext)
   at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean setImpersonationContext)
   at System.Web.HttpApplication.System.Web.Util.ISyncContext.Enter()
   at System.Web.Util.SynchronizationHelper.SafeWrapCallback(Action action)
   at System.Threading.Tasks.Task.Execute()<---

Pour le cas (2), vous obtiendrez une erreur semblable, mais d'origine avec trace de pile d'exception.

Pour .NET 4.0 et versions ultérieures, vous pouvez prendre inaperçu exceptions à l'aide de TaskScheduler.UnobservedTaskException. Pour .NET 4.5 et plus inaperçu exceptions sont avalés par défaut pour les .NET 4.0 inaperçu exception crash de votre processus.

Plus de détails ici: La tâche de la gestion des exceptions dans .NET 4.5

InformationsquelleAutor samfromlv

2

Vous pouvez utiliser Task.WhenAll comme mentionné, ou Task.WaitAll, selon que vous souhaitez que le thread d'attendre. Jetez un oeil sur le lien pour une explication des deux.

WaitAll vs WhenAll

InformationsquelleAutor christiandev

Utilisation Task.WhenAll et puis attendre les résultats:

var tCat = FeedCat();
var tHouse = SellHouse();
var tCar = BuyCar();
await Task.WhenAll(tCat, tHouse, tCar);
Cat cat = await tCat;
House house = await tHouse;
Tesla car = await tCar; 
//as they have all definitely finished, you could also use Task.Value.

mm...pas la Tâche.Valeur (peut-être qu'il existait en 2013?), plutôt tCat.Résultat, tHouse.Résultat ou de la tCar.Résultat

InformationsquelleAutor It'sNotALie.

1
```
var dn = await Task.WhenAll<dynamic>(FeedCat(),SellHouse(),BuyCar());
```
si vous souhaitez accéder au Chat, pour ce faire:
```
var ct = (Cat)dn[0];
```
C'est très simple à faire et très utile pour l'utilisation, il n'est pas nécessaire d'aller chercher une solution complexe.
- Et avec les tuples gist.github.com/jnm2/3660db29457d391a34151f764bfe6ef7
InformationsquelleAutor taurius

Avant D'Avertissement

Juste un petit headsup à ceux qui visitent ce type de threads à la recherche d'un moyen de paralléliser EntityFramework à l'aide async+attendre+de tâches ensemble d'outils de: Le modèle présenté ici est le son, cependant, quand il s'agit de la spéciale de flocon de neige de EF vous ne serez pas obtenir l'exécution en parallèle, à moins que et jusqu'à ce que vous utilisez une autre (nouvelle) db-contexte-exemple à l'intérieur de chaque et chaque *Asynchrone() l'appel en cause.

Ce genre de chose est nécessaire en raison inhérente limites de la conception de l'ef-db-contextes qui interdisent l'exécution de plusieurs requêtes en parallèle dans le même ef-db-instance de contexte.

Capitalisant sur les réponses déjà données, c'est la façon de vous assurer que vous collectez toutes les valeurs, même dans le cas où un ou plusieurs des tâches entraîne une exception:

  public async Task<string> Foobar() {
    async Task<string> Awaited(Task<Cat> a, Task<House> b, Task<Tesla> c) {
        return DoSomething(await a, await b, await c);
    }

    using (var carTask = BuyCarAsync())
    using (var catTask = FeedCatAsync())
    using (var houseTask = SellHouseAsync())
    {
        if (carTask.Status == TaskStatus.RanToCompletion //triple
            && catTask.Status == TaskStatus.RanToCompletion //cache
            && houseTask.Status == TaskStatus.RanToCompletion) { //hits
            return Task.FromResult(DoSomething(catTask.Result, carTask.Result, houseTask.Result)); //fast-track
        }

        cat = await catTask;
        car = await carTask;
        house = await houseTask;
        //or Task.AwaitAll(carTask, catTask, houseTask);
        //or await Task.WhenAll(carTask, catTask, houseTask);
        //it depends on how you like exception handling better

        return Awaited(catTask, carTask, houseTask);
   }
 }

Une alternative de mise en œuvre est plus ou moins les mêmes caractéristiques de performance pourrait être:

 public async Task<string> Foobar() {
    using (var carTask = BuyCarAsync())
    using (var catTask = FeedCatAsync())
    using (var houseTask = SellHouseAsync())
    {
        cat = catTask.Status == TaskStatus.RanToCompletion ? catTask.Result : (await catTask);
        car = carTask.Status == TaskStatus.RanToCompletion ? carTask.Result : (await carTask);
        house = houseTask.Status == TaskStatus.RanToCompletion ? houseTask.Result : (await houseTask);

        return DoSomething(cat, car, house);
     }
 }

InformationsquelleAutor XDS

Vous devez vous connecter pour publier un commentaire.