Async / Wait vs BackgroundWorker

Au cours des derniers jours, j'ai testé les nouvelles fonctionnalités de .net 4.5 et c # 5.

J'aime ses nouvelles fonctionnalités async / await. Auparavant, j'avais utilisé BackgroundWorker pour gérer des processus plus longs en arrière-plan avec une interface utilisateur réactive.

Ma question est: après avoir ces nouvelles fonctionnalités intéressantes, quand dois-je utiliser async / await et quand un BackgroundWorker ? Quels sont les scénarios communs pour les deux?

async / await est conçu pour remplacer des constructions telles que BackgroundWorker. Bien que vous puissiez certainement l' utiliser si vous le souhaitez, vous devriez pouvoir utiliser async / await, avec quelques autres outils TPL, pour gérer tout ce qui existe.

Puisque les deux fonctionnent, cela dépend de la préférence personnelle que vous utilisez quand. Qu'est-ce qui est le plus rapide pour vous ? Qu'est-ce qui est plus facile à comprendre pour vous ?

C'est probablement TL; DR pour beaucoup, mais je pense que comparer awaitavec, BackgroundWorkerc'est comme comparer des pommes et des oranges et mes pensées à ce sujet sont les suivantes:

BackgroundWorkerest destiné à modéliser une tâche unique que vous souhaitez effectuer en arrière-plan, sur un thread de pool de threads. async/ awaitest une syntaxe pour l'attente asynchrone sur les opérations asynchrones. Ces opérations peuvent ou non utiliser un thread de pool de threads ou même utiliser n'importe quel autre thread . Donc, ce sont des pommes et des oranges.

Par exemple, vous pouvez faire quelque chose comme ce qui suit avec await:

using (WebResponse response = await webReq.GetResponseAsync())
{
    using (Stream responseStream = response.GetResponseStream())
    {
        int bytesRead = await responseStream.ReadAsync(buffer, 0, buffer.Length);
    }
}

Mais, vous ne modéliseriez probablement jamais cela dans un travailleur d'arrière-plan, vous feriez probablement quelque chose comme ça dans .NET 4.0 (avant await):

webReq.BeginGetResponse(ar =>
{
    WebResponse response = webReq.EndGetResponse(ar);
    Stream responseStream = response.GetResponseStream();
    responseStream.BeginRead(buffer, 0, buffer.Length, ar2 =>
    {
        int bytesRead = responseStream.EndRead(ar2);
        responseStream.Dispose();
        ((IDisposable) response).Dispose();
    }, null);
}, null);

Remarquez la disjonction de l'élimination par rapport aux deux syntaxes et comment vous ne pouvez pas utiliser usingsans async/ await.

Mais vous ne feriez pas quelque chose comme ça avec BackgroundWorker. BackgroundWorkerest généralement destiné à modéliser une seule opération de longue durée dont vous ne souhaitez pas affecter la réactivité de l'interface utilisateur. Par exemple:

worker.DoWork += (sender, e) =>
                    {
                    int i = 0;
                    // simulate lengthy operation
                    Stopwatch sw = Stopwatch.StartNew();
                    while (sw.Elapsed.TotalSeconds < 1)
                        ++i;
                    };
worker.RunWorkerCompleted += (sender, eventArgs) =>
                                {
                                    // TODO: do something on the UI thread, like
                                    // update status or display "result"
                                };
worker.RunWorkerAsync();

Il n'y a vraiment rien avec lequel vous pouvez utiliser async / await, qui BackgroundWorkercrée le thread pour vous.

Maintenant, vous pouvez utiliser TPL à la place:

var synchronizationContext = TaskScheduler.FromCurrentSynchronizationContext();
Task.Factory.StartNew(() =>
                      {
                        int i = 0;
                        // simulate lengthy operation
                        Stopwatch sw = Stopwatch.StartNew();
                        while (sw.Elapsed.TotalSeconds < 1)
                            ++i;
                      }).ContinueWith(t=>
                                      {
                                        // TODO: do something on the UI thread, like
                                        // update status or display "result"
                                      }, synchronizationContext);

Dans ce cas, le TaskSchedulercrée le thread pour vous (en supposant la valeur par défaut TaskScheduler), et pourrait utiliser awaitcomme suit:

await Task.Factory.StartNew(() =>
                  {
                    int i = 0;
                    // simulate lengthy operation
                    Stopwatch sw = Stopwatch.StartNew();
                    while (sw.Elapsed.TotalSeconds < 1)
                        ++i;
                  });
// TODO: do something on the UI thread, like
// update status or display "result"

À mon avis, une comparaison majeure est de savoir si vous faites état de progrès ou non. Par exemple, vous pourriez avoir un BackgroundWorker likececi:

BackgroundWorker worker = new BackgroundWorker();
worker.WorkerReportsProgress = true;
worker.ProgressChanged += (sender, eventArgs) =>
                            {
                            // TODO: something with progress, like update progress bar

                            };
worker.DoWork += (sender, e) =>
                 {
                    int i = 0;
                    // simulate lengthy operation
                    Stopwatch sw = Stopwatch.StartNew();
                    while (sw.Elapsed.TotalSeconds < 1)
                    {
                        if ((sw.Elapsed.TotalMilliseconds%100) == 0)
                            ((BackgroundWorker)sender).ReportProgress((int) (1000 / sw.ElapsedMilliseconds));
                        ++i;
                    }
                 };
worker.RunWorkerCompleted += (sender, eventArgs) =>
                                {
                                    // do something on the UI thread, like
                                    // update status or display "result"
                                };
worker.RunWorkerAsync();

Mais, vous ne traiteriez pas une partie de cela parce que vous feriez glisser-déposer le composant de travail d'arrière-plan sur l'aire de conception d'un formulaire - quelque chose que vous ne pouvez pas faire avec async/ awaitet Task... c'est-à-dire que vous avez gagné ' t créer manuellement l'objet, définir les propriétés et définir les gestionnaires d'événements. vous souhaitez remplir uniquement le corps des DoWork, RunWorkerCompletedet des ProgressChangedgestionnaires d'événements.

Si vous "convertissez" cela en async / await, vous feriez quelque chose comme:

     IProgress<int> progress = new Progress<int>();

     progress.ProgressChanged += ( s, e ) =>
        {
           // TODO: do something with e.ProgressPercentage
           // like update progress bar
        };

     await Task.Factory.StartNew(() =>
                  {
                    int i = 0;
                    // simulate lengthy operation
                    Stopwatch sw = Stopwatch.StartNew();
                    while (sw.Elapsed.TotalSeconds < 1)
                    {
                        if ((sw.Elapsed.TotalMilliseconds%100) == 0)
                        {
                            progress.Report((int) (1000 / sw.ElapsedMilliseconds))
                        }
                        ++i;
                    }
                  });
// TODO: do something on the UI thread, like
// update status or display "result"

Sans la possibilité de faire glisser un composant sur une surface Designer, c'est vraiment au lecteur de décider lequel est «meilleur». Mais, pour moi, c'est la comparaison entre awaitet BackgroundWorker, pas si vous pouvez attendre des méthodes intégrées comme Stream.ReadAsync. par exemple, si vous utilisiez BackgroundWorkercomme prévu, il pourrait être difficile de le convertir await.

Autres réflexions: http://jeremybytes.blogspot.ca/2012/05/backgroundworker-component-im-not-dead.html

Voici une bonne introduction: http://msdn.microsoft.com/en-us/library/hh191443.aspx La section Threads est exactement ce que vous recherchez:

Les méthodes asynchrones sont destinées à être des opérations non bloquantes. Une expression d'attente dans une méthode async ne bloque pas le thread actuel pendant l'exécution de la tâche attendue. Au lieu de cela, l'expression signe le reste de la méthode en tant que continuation et renvoie le contrôle à l'appelant de la méthode async.

Les mots-clés async et await ne provoquent pas la création de threads supplémentaires. Les méthodes async ne nécessitent pas de multithreading car une méthode async ne s'exécute pas sur son propre thread. La méthode s'exécute sur le contexte de synchronisation actuel et utilise l'heure sur le thread uniquement lorsque la méthode est active. Vous pouvez utiliser Task.Run pour déplacer le travail lié au processeur vers un thread d'arrière-plan, mais un thread d'arrière-plan n'aide pas avec un processus qui attend simplement que les résultats soient disponibles.

L'approche asynchrone de la programmation asynchrone est préférable aux approches existantes dans presque tous les cas. En particulier, cette approche est meilleure que BackgroundWorker pour les opérations liées aux E / S car le code est plus simple et vous n'avez pas à vous prémunir contre les conditions de concurrence. En combinaison avec Task.Run, la programmation asynchrone est meilleure que BackgroundWorker pour les opérations liées au processeur, car la programmation async sépare les détails de coordination de l'exécution de votre code du travail que Task.Run transfère au pool de threads.

BackgroundWorker est explicitement étiqueté comme obsolète dans .NET 4.5:

• dans le livre de Joseph Albahari, Ben Albahari "C # 5.0 en bref: la référence définitive"
• Réponse de Stephen Cleary à ma question "N'est-ce pas. NET 4.0 TPL qui a rendu obsolètes les modèles asynchrones APM, EAP et BackgroundWorker?"

L'article MSDN «Programmation asynchrone avec Async et Await (C # et Visual Basic)» indique:

L'approche asynchrone de la programmation asynchrone est préférable aux approches existantes dans presque tous les cas . En particulier, cette approche est meilleure que BackgroundWorker pour les opérations liées aux E / S car le code est plus simple et vous n'avez pas à vous prémunir contre les conditions de concurrence. En combinaison avec Task.Run, la programmation asynchrone est meilleure que BackgroundWorker pour les opérations liées au processeur, car la programmation async sépare les détails de coordination de l'exécution de votre code du travail que Task.Run transfère vers le pool de threads

METTRE À JOUR

• en réponse au commentaire de @ eran-otzap :
  "pour les opérations liées aux E / S car le code est plus simple et vous n'avez pas à vous prémunir contre les conditions de concurrence " Quelles conditions de concurrence peuvent se produire, pourriez-vous donner un exemple? "

Cette question aurait dû être posée dans un message distinct.

Wikipedia a une bonne explication des conditions de course . La partie nécessaire de celui-ci est le multithreading et du même article MSDN Programmation asynchrone avec Async et Await (C # et Visual Basic) :

Les méthodes asynchrones sont destinées à être des opérations non bloquantes. Une expression d'attente dans une méthode async ne bloque pas le thread actuel pendant l'exécution de la tâche attendue. Au lieu de cela, l'expression signe le reste de la méthode en tant que continuation et renvoie le contrôle à l'appelant de la méthode async.

Les mots-clés async et await ne provoquent pas la création de threads supplémentaires. Les méthodes async ne nécessitent pas de multithreading car une méthode async ne s'exécute pas sur son propre thread. La méthode s'exécute sur le contexte de synchronisation actuel et utilise l'heure sur le thread uniquement lorsque la méthode est active. Vous pouvez utiliser Task.Run pour déplacer le travail lié au processeur vers un thread d'arrière-plan, mais un thread d'arrière-plan n'aide pas avec un processus qui attend juste que les résultats soient disponibles.

L'approche asynchrone de la programmation asynchrone est préférable aux approches existantes dans presque tous les cas. En particulier, cette approche est meilleure que BackgroundWorker pour les opérations liées aux E / S car le code est plus simple et vous n'avez pas à vous prémunir contre les conditions de concurrence. En combinaison avec Task.Run, la programmation asynchrone est meilleure que BackgroundWorker pour les opérations liées au processeur, car la programmation async sépare les détails de coordination de l'exécution de votre code du travail que Task.Run transfère vers le pool de threads

Autrement dit, "Les mots clés async et await ne provoquent pas la création de threads supplémentaires".

Pour autant que je me souvienne de mes propres tentatives lorsque j'étudiais cet article il y a un an, si vous avez exécuté et joué avec un échantillon de code du même article, vous pourriez tomber dans la situation où ses versions non asynchrones (vous pouvez essayer de convertir à vous-même) bloquer indéfiniment!

Vous pouvez également rechercher des exemples concrets sur ce site. Voici quelques exemples:

• Appel d'une méthode asynchrone avec c # 5.0
• Pourquoi ce code échoue-t-il lorsqu'il est exécuté via TPL / Tasks?
• Wait vs Task.Wait - Impasse?