Discussion :

[GTSLASH]

Pour faire simple on peut dire je pense que l'appel a une ou plusieurs tache peut se faire dans la methode en cours sans bloquer le Thread de l'interface utilisateur.

Sans le systeme 'await' le thread de l'UI resterait bloqué jusqua ce qu'il ait recu la reponse.

C'est le principal atout je trouve. Plus besoin d'utiliser un BusyIndicator ou autre pour empecher l'utilisateur d'utiliser l'UI. car un beau 'Pas de reponse' apparaitrai si il utiliserai le thread d'affichage. Et ce sans avoir besoin de passer par la tuyauterie d'un BackgroundWorker qui demande beaucoup plus de code.

Et avec les processeurs multi-coeur actuel il etait temp d'avoir les outils et framework nous permetant de les utilisés pleinements.

[The_badger_man]

Apres je mettrai un bémol, puisque du coup il faut pensez qu'une méthode "async" bien qu'aillant exactement la tête d'une méthode synchrone ne l'ai pas.

c'est con , mais j'ai tellement pris l'habitude de lancer un appel asynchrone par une méthode et de revenir par une autre que du coup cela semble illogique de procéder ainsi.

Je pense, que du coup,il faut bien mettre en évidence le faite que la méthode est asynchrone (commentaire / region ? ).

C'est pour ça qu'il est recommandé de terminer le nom d'une méthode asynchrone par "Async" (comme dans l'exemple avec DownloadStringTaskAsync). C'est ce que fait Microsoft dans son framework.

[LSMetag]

@tomlev

Merci pour tes explications très claires. Je m'étais documenté sur ce pattern mais n'ai encore pas eu l'occasion de le tester.

Pour moi c'est assez intuitif sur le papier. Après je me demande comment ça marche quand on veut traiter des états intermédiaires (pas complété pour par exemple faire des barres de progression). J'espère qu'il ne faut pas multiplier les await.

Il faut voir également quels avantages cela procurerait par rapport à de l'Ajax, côté web (niveau logiciel, la question ne se pose pas).

J'ai répondu "oui" au sondage, car j'y pense depuis un moment.

[Gugelhupf]

Bonsoir,

N'aurait-t-il pas été possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
private void btnDownload_Click(object sender, EventArgs e)
{
    new Thread(() => {
        var client = new WebClient();
        string data = client.DownloadString("http://monserveur.com/data");
        txtData.Text = data;
    }).Start();
}

Ou bien est-ce que c'est interdit/déconseillé ?

Merci.

[LSMetag]

Bonsoir,

N'aurait-t-il pas été possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
private void btnDownload_Click(object sender, EventArgs e)
{
    new Thread(() => {
        var client = new WebClient();
        string data = client.DownloadString("http://monserveur.com/data");
        txtData.Text = data;
    }).Start();
}

Ou bien est-ce que c'est interdit/déconseillé ?

Merci.

D'après moi ce n'est pas impossible. Après je trouve que ça rajoute en complexité.
D'autre part, ça ne tire pas partie des Task Parallel Library. A quoi bon chercher à refaire la roue (souvent en moins bien) ? La programmation des threads façon .NET 1.1, j'avoue que ça m'énerve vite.

Pour moi le mot clé "Await" est comme un synonyme de "Break" qui nous dit :

- Cette méthode exécute un processus en parallèle. Le processus principal n'est pas là.

[tomlev]

N'aurait-t-il pas été possible de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
private void btnDownload_Click(object sender, EventArgs e)
{
    new Thread(() => {
        var client = new WebClient();
        string data = client.DownloadString("http://monserveur.com/data");
        txtData.Text = data;
    }).Start();
}

Ou bien est-ce que c'est interdit/déconseillé ?

C'est possible, mais ça présente plusieurs inconvénients :

• C'est nettement plus lourd en terme de syntaxe
• Télécharger des données est intrinsèquement une tâche d'entrée/sortie, il n'est donc pas utile de monopoliser un thread pour le faire. Ce thread passera l'essentiel de son temps bloqué à attendre que le téléchargement se termine...
• En l'état, ça ne fonctionnera pas, parce que txtData.Text = data; ne peut être exécuté que sur le thread de l'UI. Modifier l'UI depuis un autre thread provoquera une exception. Pour contourner ce problème, il faudrait passer par la méthode Invoke pour exécuter ce code sur le thread de l'UI, ce qui alourdirait encore plus l'ensemble.

[Invité]

Le seul truc chiant c'était le débogage mais avec VS2013 c'est plus simple. Sinon c'est bien plus simple d'utiliser ce nouveau modèle de programmation asynchrone.

[Nathanael Marchand]

Le seul piège c'est qu'il faut pas confondre await et parallèlisme.
Une boucle avec de l'async dedans ne traite pas les différents éléments en parallèle

[tomlev]

Le seul truc chiant c'était le débogage

J'avoue, c'est le truc qui me prend le plus la tête... quand tu as une exception, la pile est difficile à interpréter. Mais comme tu dis, VS2013 a l'air d'améliorer ça (j'ai pas encore trouvé le temps de tester)

[atha2]

C'est possible, mais ça présente plusieurs inconvénients :

• C'est nettement plus lourd en terme de syntaxe

C'est une question de point de vue. Même si c'est plus long à écrire, la syntaxe de Gugelhupf montre ce qu'on fait et n'importe quel développeur comprend le code. Je suis développeur Java et je suis régulièrement amené à travailler sur des développements C#. Sans cet article, je n'aurai probablement mal compris ce code et perdu pas mal de temps à le débugger.

• Télécharger des données est intrinsèquement une tâche d'entrée/sortie, il n'est donc pas utile de monopoliser un thread pour le faire. Ce thread passera l'essentiel de son temps bloqué à attendre que le téléchargement se termine...

Il y a probablement quand même un thread qui gère les I/O en background et va prévenir le thread graphique qu'il faut reprendre l’exécution de la fonction. Même si celui nous est masqué et est géré par .NET.

• En l'état, ça ne fonctionnera pas, parce que txtData.Text = data; ne peut être exécuté que sur le thread de l'UI. Modifier l'UI depuis un autre thread provoquera une exception. Pour contourner ce problème, il faudrait passer par la méthode Invoke pour exécuter ce code sur le thread de l'UI, ce qui alourdirait encore plus l'ensemble.

Il existe une méthode, dont le nom m'échappe, qui permet, en une instruction, de mettre à jour un composant graphique (qui doit utiliser Invoke en interne). La syntaxe doit ressembler à quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

updateInUIThread(txtData, "Text", data);

Au final, sur ce que j'en vois, le modèle async/await est surement très pratique une fois bien maitrisée. Mais j'ai du mal avec le mot clé "async" alors que le début de la méthode (avant le await) est exécuté de façon synchrone

[tomlev]

Il y a probablement quand même un thread qui gère les I/O en background et va prévenir le thread graphique qu'il faut reprendre l’exécution de la fonction. Même si celui nous est masqué et est géré par .NET.

Je sais pas exactement comment ça fonctionne en interne, mais en gros ça repose sur le mécanisme de "IO completion port". En tous cas ce qui est sûr c'est que dans ce scénario il n'y a pas un thread de travail qui reste bloqué à attendre la fin d'une opération.

Il existe une méthode, dont le nom m'échappe, qui permet, en une instruction, de mettre à jour un composant graphique (qui doit utiliser Invoke en interne). La syntaxe doit ressembler à quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

updateInUIThread(txtData, "Text", data);

Il n'existe pas de méthode comme ça en standard, mais ce ne serait pas très difficile de la créer.

Mais j'ai du mal avec le mot clé "async" alors que le début de la méthode (avant le await) est exécuté de façon synchrone

Et alors ? une opération n'est jamais entièrement asynchrone, il y a toujours des parties synchrones...

[DotNET74]

Je l'utilise car ça évite de geler l'interface lors de chargement de longue liste d'élément ou en attente de données provenant du web.

Et c'est pas trop compliqué non plus donc pourquoi s'en privé !

[jmnicolas]

Tu peux toujours passer à VS2012 tout en continuant à cibler .NET 4.0 ; en utilisant le package Microsoft.Bcl.Async mentionné plus haut, ça te permettrait d'utiliser async/await.

Petite boite, petit budget (informatique du moins), la crise (qui a bon dos) ... tout ça - tout ça ...

Et VS Express est trop amputé pour être réellement utile ...

Si ça continue je vais devoir m'inscrire en temps qu'étudiant pour avoir des licences Microsoft gratuites

[redcurve]

Petite boite, petit budget (informatique du moins), la crise (qui a bon dos) ... tout ça - tout ça ...

Et VS Express est trop amputé pour être réellement utile ...

Si ça continue je vais devoir m'inscrire en temps qu'étudiant pour avoir des licences Microsoft gratuites

Ah carrément heu Vst 2012 via bittorent alors

[vohufr]

Je trouve ça vraiment pas mal :p

[Reward]

Bonjour Tom,

Pour ma part je n'ai pas encore eu l'occasion de tester ce nouveau mot clé.

Je suis par contre un grand utilisateur des grands background worker pour ne pas figer mon interface et permettre une gestion de barre de progression.

[DeVaK]

J'utilise pas async/await, même si j'en avais entendu parler vaguement. Je suis sous VS 2010 au boulot donc vouala...

Par contre c'est vrai que la feature me plait beaucoup! C'est très simple à comprendre et ça facilite le processus. Je vois déjà une application où cela aurait été très pratique...

[Guulh]

C'est une question de point de vue. Même si c'est plus long à écrire, la syntaxe de Gugelhupf montre ce qu'on fait et n'importe quel développeur comprend le code. Je suis développeur Java et je suis régulièrement amené à travailler sur des développements C#. Sans cet article, je n'aurai probablement mal compris ce code et perdu pas mal de temps à le débugger.

Donc pour suivre la même logique, il faut se passer de Linq parce que seul .Net l'a, il faut se passer de WPF, WCF pour la même raison, ne pas faire d'objet pour ne pas dérouter ceux qui font du C...
Les langages rajoutent du sucre au fur et à mesure. Leurs concepteurs détectent des patterns très fréquents, et proposent des syntaxes simplifiées, ce qui minimise les risques de bug (pas de IndexOutOfRangeException avec un foreach!) et uniformise le code, ce qui en facilite la maintenance.
Pour l'instant, j'ai l'impression que Microsoft a réussi à faire utiliser toutes les features qu'ils ont ajoutées (même si je n'ai pas encore beaucoup vu d'usages de in/out pour la co-Contravariance, ou de dynamic pour le dispatch dynamique), pqrce au'elles correspondaient à un besoin réel et pragamatique.

Après, comme tout nouvel outil, je suis curieux de voir comment il sera mal utilisé: est-ce qu'il sera abusé par des gasr qui veulent trop bien faire ou qui ont rien capté Surveillons thedailywtf.com pour le savoir

[Nicam]

Pour ma part, je ne vois pas plus simple pour mettre un peu d'asynchrone dans du code. Pour Quelque chose de plus complexe (et maitrisable plus finement), il y a les tasks...

VSnet 2012, lorsqu'on est une entreprise (hors autoentrepreneur), ca coute environ 500 euros HT (version pro), c'est presque donné (regardé le coût des plugins Xamarin pour comparaison ...)

[tomlev]

Par contre j'ai une petite question : c'est utile seulement quand il n'y a qu'une seule donnée de retour et des fonctionnements asynchrone très simple non?

Non, pas forcément. De toute façon "une seule donnée de retour", ça ne veut pas dire grand chose, car s'il y en a plusieurs, tu peux toujours les agréger dans une classe. Et tu peux tout à fait faire des traitements complexes avec des boucles, des try/catch, des using, etc. Il y a quelques limitations (pas de await dans un bloc catch ou finally, pas de paramètre ref ou out dans une méthode asynchrone, etc), mais dans l'ensemble tu peux faire tout ce que tu fais d'habitude.

Par exemple si je veux appellé une fonction qui renvoi un résultat mais qui veut aussi incrémenter une barre de progression ça sera pas possible avec des async/await si je n'm'abuse?

Si, bien sûr, et beaucoup plus facilement qu'avec des threads, car tu peux directement mettre à jour l'UI sans avoir à utiliser Invoke. Par exemple ça peut donner quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
private async Task<long> CopyFile(string source, string destination)
{
    using (var sourceStream = new FileStream(source, FileMode.Open, FileAccess.Read))
    using (var destinationStream = new FileStream(destination, FileMode.OpenOrCreate, FileAccess.Write))
    {
        progressBar1.Minimum = 0;
        progressBar1.Maximum = (int)sourceStream.Length;
        progressBar1.Value = 0;
        long totalBytesCopied = 0;
        int nRead;
        byte[] buffer = new byte[8192];
        while ((nRead = await sourceStream.ReadAsync(buffer, 0, buffer.Length)) > 0)
        {
            await destinationStream.WriteAsync(buffer, 0, nRead);
            totalBytesCopied += nRead;
            progressBar1.Value = (int)totalBytesCopied;
        }
        return totalBytesCopied;
    }
}

(bon, bien sûr c'est pas un très bon exemple, il y a des façons plus simples de copier un fichier, mais ça illustre bien le genre de choses qu'on peut faire...)