plusieurs attend vs Tâche.WaitAll équivalent?

En termes de performances, ces 2 méthodes exécuter GetAllWidgets() et GetAllFoos() en parallèle?

Est-il une raison pour utiliser l'un plutôt que l'autre? Il semble y avoir beaucoup qui se passe derrière les coulisses avec le compilateur, donc je ne trouve pas ça clair.

============= MethodA: l'Utilisation de plusieurs attend ======================

public async Task<IHttpActionResult> MethodA()
{
    var customer = new Customer();

    customer.Widgets = await _widgetService.GetAllWidgets();
    customer.Foos = await _fooService.GetAllFoos();

    return Ok(customer);
}

=============== MethodB: À L'Aide De La Tâche.WaitAll =====================

public async Task<IHttpActionResult> MethodB()
{
    var customer = new Customer();

    var getAllWidgetsTask = _widgetService.GetAllWidgets();
    var getAllFoosTask = _fooService.GetAllFos();

    Task.WaitAll(new List[] {getAllWidgetsTask, getAllFoosTask});

    customer.Widgets = getAllWidgetsTask.Result;
    customer.Foos = getAllFoosTask.Result;

    return Ok(customer);
}

=====================================

  • Dans ton premier exemple, les deux méthodes seront appelés séquentiellement et dans la seconde, ils vont être exécutés en parallèle, de sorte qu'ils ne sont pas équivalents. Aussi, dans votre deuxième méthode de blocage lors de l'exécution de ces tâches.
  • MethodA exécutera _fooService.GetAllFoos() uniquement lorsque _widgetService.GetAllWidgets() a fini, methodB va l'exécuter lorsque la Tâche inachevée de _fooService.GetAllFoos() retourne.
InformationsquelleAutor vidalsasoon | 2015-08-20
  1. 88

    La première option de ne pas exécuter les deux opérations simultanément. Il exécutera la première et attendre son achèvement, et seulement ensuite la deuxième.

    La seconde option est d'exécuter les deux en même temps mais va attendre pour eux de façon synchrone (c'est à dire tout en bloquant un thread).

    Vous ne devez pas utiliser deux options depuis la première est terminée plus lent que le second, et le second bloque un fil sans le besoin.

    Vous devez attendre pour les deux opérations de manière asynchrone avec Task.WhenAll:

    public async Task<IHttpActionResult> MethodB()
{
    var customer = new Customer();

    var getAllWidgetsTask = _widgetService.GetAllWidgets();
    var getAllFoosTask = _fooService.GetAllFos();

    await Task.WhenAll(getAllWidgetsTask, getAllFoosTask);

    customer.Widgets = await getAllWidgetsTask;
    customer.Foos = await getAllFoosTask;

    return Ok(customer);
}

    Noter qu'après Task.WhenAll rempli les deux tâches déjà achevés à ce qui les attend s'effectue immédiatement.

    • Merci. C'est ce dont j'avais besoin. L' ".Suite" a été me tracasse, et votre réponse évite que.
    • sûr.. tout moment.
    • Vous pouvez également complètement ignorer await Task.WhenAll(getAllWidgetsTask, getAllFoosTask); et juste attendre tâches (juste le début de la deuxième tâche en attente du premier).
    • c'est vrai, mais c'est un peu plus efficace de "suspendre" qu'une seule fois.
    • sonne comme une bonne raison, il n'y a pas vraiment d'intérêt à changer de contexte juste pour attendre de nouveau.
    • exactement
    • Cela semble un peu inélégant, comme nous utilisons des "en attente" sur les deux tâches après nous savons déjà qu'ils ont terminé. Quel est le problème avec juste l'aide de l' .Résultat de la propriété?
    • quel est le problème avec l'aide de await? await ne se soucie pas de savoir si la tâche est terminée ou non (même optimise si elle est).
    • Il y a exactement une différence entre les deux. Result encapsule toutes les exceptions dans un AggregateException, que vous devez ensuite déballer dans tous de votre code de gestion d'erreur. await déballe pour vous. Autre que cela, elles sont identiques.
    • pas de raison je pense... je l'avais jamais vu attendent utilisé dans ce contexte avant, et j'ai juste pensé async implicite de quelque chose qui devrait prendre un certain temps pour terminer. Grâce à vous et Servy pour expliquer.

    InformationsquelleAutor i3arnon
  2. 15

    Réponse courte: Non.

    Task.WaitAll est le blocage, await revient la tâche dès qu'il se produit et enregistre la partie restante de la fonction et de la poursuite.

    "L'essentiel" en attente de la méthode que vous cherchiez est Task.WhenAll qui crée en fait une nouvelle Task qui se termine lorsque toutes les tâches qui ont été remis à la fonction de faire.

    Comme suit: await Task.WhenAll({getAllWidgetsTask, getAllFoosTask});

    Qui est pour le blocage de la matière.

    Également votre première fonction ne pas exécuter les deux fonctions en parallèle. Pour obtenir ce travail avec await vous devriez écrire quelque chose comme ceci:

    var widgetsTask = _widgetService.GetAllWidgets();
var foosTask = _fooService.GetAllWidgets();
customer.Widgets = await widgetsTask;
customer.Foos = await foosTask;

    Cela rendra le premier exemple de loi très similaire à la Task.WhenAll méthode.

    InformationsquelleAutor Nitram
  3. 0

    Seulement votre deuxième option exécuter en parallèle. Votre première attendent sur chaque appel dans l'ordre.

    InformationsquelleAutor nvoigt
  4. 0

    Dès que vous lancez la méthode asynchrone, il va commencer l'exécution. Si elle va à l'exécution du thread courant (et donc exécuté de manière synchrone) ou il se déroulera asynchrone n'est pas possible de déterminer.

    Ainsi, dans votre premier exemple, la première méthode consiste à commencer à travailler, mais alors vous artificiellement arrête l'écoulement du code avec les attendent. Et donc la deuxième méthode ne sera pas invoquée avant la première est effectuée en cours d'exécution.

    Le deuxième exemple évoque à la fois les méthodes sans arrêter l'écoulement avec un attendent. Ainsi, ils seront susceptibles de s'exécuter en parallèle si les méthodes sont asynchrones.

    InformationsquelleAutor Kasper Holdum