c2i.fr - Thread

Etendre une API .NET existante pour supporter les opérations asynchrones

Sun, 15 Apr 2012 05:51:48 GMT

Laurent Kempé (après 2 ans d'absence tout comme moi ;-)) vient de publier un article sur comment adapter une opération synchrone en une opération asynchrone avec le framework 4.0.

(Il savait certainement que j'était en train de préparer un article du genre et s'est donc précipité pour publier le sien ;-))

Ceci dit il applique sa méthodologie à l'excellente bibliothèque Open Source RestSharp.

http://www.techheadbrothers.com/Astuces.aspx/etendre-api-dotnet-existante-supporter-operations-asynchrones

NB ; j'aurais utilisé plutôt un Task.Factory que l'utilisation directe du pool de thread.

Ceci dit, dans le même temps, Stephen Toub de l'équipe de pfx, publie un billet sur : Faut-il ou non exposer un wrapper asynchrone pour ses méthodes synchrones ? (billet faisant suite à un précédent billet sur le même sujet).

Donc en gros il conclu : c'est sympa d'exposer ses méthodes en asynchrone, mais c'est mieux de laisser la décision à son consommateur. Je pense que sa principale crainte, c'est que la plupart des personnes implémentant ces méthodes en asynchrones tombent dans des pièges assez sournois qui génèrent des bogues inattendus (il a peur surtout des deadlocks).

Async/Await FAQ

Fri, 13 Apr 2012 06:23:59 GMT

Voici un billet de l'équipe de TPL très intéressant regroupant l'ensemble des questions que l'on peut se poser quand on veut programmez de façon asynchrone (ici avec .NET 4.5 et le fameux couple async/await).

Bien entendu, en face de ces questions, il présente des liens vers les différentes réponses (sinon, ca n'aurait aucun intérêt !!!).

Il décrit notamment les mécanismes qui découlent de la déclaration d'une méthode async (ce que fait le compilateur), si l'on peut marquer n'impoprte quelle méthode comme async, est-ce intéressant de créer systématiquement une méthode async pour une méthode syncro existante, dois-je invoquer la méthode Dispose , await utilise t'il le SynchronizationContext courant, quels sont les compatibilités avec les autres modèles asynchrones (APM, EAP), etc.

Bref, un article "de base" pour aborder la programmation asynchrone avec .NET 4.5.

Enregistrer ses logs par batch en asynchrône par Jeffrey Richter

Tue, 10 Apr 2012 06:37:15 GMT

Jeffrey Ritcher publi peu mais ses publications sont toujours très intéressantes.

Spécialiste du multithreading depuis de nombreuses années, son article discute d'une implémentation de l'enregistrement de logs par lots.

Le scénario est le suivant : vous avez une application, vous voulez loguer des informations, mais au lieu de le faire au fil de l'eau, vous voulez le faire par lot et de façon asynchrône.

Il analyse donc les pièges dans lesquels on risque de tomber et propose une solution à base de Spinlock pour éviter de bloquer les thread.

http://www.wintellect.com/CS/blogs/jeffreyr/archive/2012/04/09/asynchronous-batch-logging-without-blocking-threads.aspx

Les threads dans Windows 8 Metro

Mon, 26 Mar 2012 07:58:53 GMT

Jerome Laban a publié un petit article très intéressant ce week-end sur les threads dans Windows 8 Metro.

Il note la suppression de la classe Thread de WinRT (ou plus exactement, la décision de ne pas mettre cette classe dans WinRT) et l'obligation (avantageuse) d'utiliser Task & co.

Un petit billet à lire...

Encapsuler un appel de web service avec les Tasks

Fri, 17 Feb 2012 16:57:40 GMT

Dans le précédent article, je vous montrais comment prototyper un service pour qu’il puisse être consommer de façon asynchrone de façon “moderne”.

Seulement il se peut que votre service encapsule l’appel à un service WCF ou à un service Web “classique”.

Prenons un exemple de WebService tout simple :

[ServiceContract]
public interface IService1
{
    [OperationContract]
    string GetLastClientName(string countryName);
}

public class Service1 : IService1
{

    public string GetLastClientName(string countryName)
    {
        if (countryName == "FR")
            return "Richard Clark";
        return null;
    }
}

Je sais, ce n’est pas le service du siècle.

Maintenant, dans le code de l’application cliente, ajouter une référence de service en vérifiant bien que Visual Studio génère les méthodes asynchrones :

Visual Studio génère donc les méthodes BeginGetLastClientName et EndGetLastClientName (il génère également GetLastClientNameAsync, mais ici, l’approche est évènementielle).

Personnellement, j’ai toujours eu du mal avec ce pattern, je ne l’ai jamais trouvé “friendly”.

Heureusement, Task permet d’encapsuler tout cela très facilement.

On va donc créer une classe service qui sera un wrapper du service web. Et l’on va lui ajouter une méthode GetLastClientNameAsync qui retournera une Task<string> :

public class MyService
{
    private readonly Service1Client _client = new Service1Client();
    
    public Task<string> GetLastClientNameAsync(string country)
    {
        return Task<string>.Factory.FromAsync(
            _client.BeginGetLastClientName,
            _client.EndGetLastClientName, 
            country, 
            null);
    }
}

Et voilà, c’est tout. On peut maintenant utiliser notre web service de façon très simple et de façon asynchrone :

var service = new MyService();

service.GetLastClientNameAsync("FR")
    .ContinueWith(t =>
{
    if (t.IsFaulted)
    {
        Console.WriteLine(t.Exception.InnerException.Message);
        return;
    }
    Console.WriteLine(t.Result);
}, TaskScheduler.FromCurrentSynchronizationContext());

Cool non ?

Pattern d'appel asynchrone dans vos services

Fri, 17 Feb 2012 13:48:27 GMT

Imaginons une opération exécutée par un service qui risque de durer un certain temps (comme dirait Fernand Raynaud ;-))

Vous avez alors deux options pour l'exposition de votre méthode :

mode synchrone
mode asynchrone

Si vous êtes développeur chez Microsoft pour Windows 8, on vous dira que si votre méthode risque de durer plus de 50ms, alors vous devez impérativement exposer votre méthode de façon asynchrone. Et une bonne façon de nommer votre méthode, est de la suffixer par Async.

Qui dit asynchrone dit également comment le client va pouvoir consommer le résultat.

Approche évènementielle

Une solution envisagée par les premières versions du Framework .NET était d’être signifié par un évènement.

On créait une instance d’une classe,
On s’abonnait à un évènement de l’objet,
On appelait une méthode de la classe qui déclenchait l’évènement quand elle avait finie.

Exemple : System.Net.WebClient avec DownloadFileCompleted par exemple.

Approche incompréhensible

La 2ème approche consiste a utiliser le pattern recommandé par Microsoft (dès le Framework 1.0) qui repose sur le delegate AsyncCallback et l’interface IAsyncResult. Personnellement, malgré des années d’utilisation du framework, j’ai vraiment du mal avec ce pattern! (j’ai à chaque fois besoin d’une documentation pour me rappeler comment elle fonctionne).

Vous lancez votre méthode “longue” via un Beginxxx qui doit attendre dans ses arguments un AsyncCallBack
Dans le AsyncCallback, vous récupérez le résultat via un Endxxx sous forme de IAsyncResult qui possède le vrai résultat.

Bon, je n’irais pas plus loin…

Approche “moderne”

Cette fois, grâce aux dernières technologies implémentées dans le Framework, on va pouvoir simplifier grandement cela.

Notez que j’ai utilisé le mot Framework. Cela signifie que c’est possible dès le framework 4.0 qui intègre les nouvelles classes Task & co. Avec le futur Framework 4.5, je pourrais utiliser le mot Compilateur car en utilisant les termes “async” et “await”, toute la plomberie exposée ci-dessous sera implémentée.

Bref, ici, on est avec le Framework 4.0. Donc imaginons un service, une classe, avec une méthode qui prend un certain temps. La seule astuce consiste à créer une nouvelle méthode, attendant les même arguments mais qui, au lieu de retourner un TResult, retourne un Task<TResult>. Exemple :

public string GetFullName(string firstName, string lastName)
{
    return string.Format("{0} {1}", firstName, lastName);
}

public Task<string> GetFullNameAsync(string firstName, string lastName)
{
    // TODO
}

Il me semble (A CONFIRMER) que Microsoft avec Windows 8 va encore plus loin puisque dans notre cas, la méthode GetFullName sera private donc non exposée pour d’éventuels clients, parce qu’elle dépasse les fameux 50ms.

Remarquez que j’utilise comme convention de suffixer ma méthode par Async (l’idée ne vient pas de moi, je ne fais que copier les directives de MS ). L’avantage, c’est qu’au moins on sait à quoi on a affaire.

Donc il nous faut maintenant implémenter notre méthode GetFullNameAsync.

Ici, mon code est simple, et même simplissime.

Mais vous pouvez imaginer que votre méthode GetFullName appelle par exemple un autre service qui interroge une base de données SQL Azure distante, donc qui potentiellement, risque de prendre du temps (non pas que SQL Azure soit lent, loin de moi l’idée, mais votre connexion réseau elle, peut très certainement avoir des ratés). Donc on pourrait dans ce cas écrire :

public Task<string> GetFullNameAsync(string firstName, string lastName)
{
    return Task<string>.Factory.StartNew(() => GetFullName(firstName, lastName));
}

C’est également ce que j’appellerai un cas simple car tout se fait dans le même thread.

Là ou cela se complique, c’est si votre méthode (GetFullName) appelle d’autres méthodes qui peuvent lancer d’autres threads. Votre autre service peut par exemple appeler en interne son repository en asynchrone également. Donc on risque d’avoir des enchainements de Task.

Heureusement dans le Framework, vous avez la classe qui gère cela pour vous, j’ai nommé : TaskCompletionSource.

Concrètement, cela donne ceci :

public Task<string> GetFullNameAsync(string firstName, string lastName)
{
    var tcs = new TaskCompletionSource<string>();

    // lancement asynchrone
    Task<string>.Factory
        .StartNew(() => GetFullName(firstName, lastName))
        .ContinueWith(
            task =>
            {
                // une erreur ?  
                if (task.IsFaulted)
                {
                    tcs.TrySetException(task.Exception.GetBaseException());
                }
                // annulé ?
                else if (task.IsCanceled)
                {
                    tcs.TrySetCanceled();
                }
                // on retourne le résultat 
                else
                {
                    tcs.TrySetResult(task.Result);
                }
            });

    return tcs.Task;
}

Remarquez l’utilisation des Tryxxx car il se peut qu’il y ai un appel concurrentiel de l’affectation du résultat, exception ,etc.

Pour le client cela devient simple (et c’est compatible avec les futurs async/await), ici avec resynchronisation dans le thread de l’UI :

service.GetFullNameAsync("Richard", "Clark")
    .ContinueWith(
       t => Console.WriteLine(t.Result),
       TaskScheduler.FromCurrentSynchronizationContext());

Gestion d'exception avec les Tasks

Tue, 14 Feb 2012 13:24:49 GMT

Nous avons vu dans un précédent article comment utiliser Task pour effectuer des opérations dans un autre thread.

Malheureusement, comme tout le monde n’est pas parfait, il se peut que cette exécution se passe mal et qu’une exception se produise. Reprenons notre application WPF :

<StackPanel>
    <Button Content="Clic" Click="Button_Click" />
    <TextBlock x:Name="infos"/>
</StackPanel>

Avec un code qui génère une exception :

private void Button_Click(object sender, RoutedEventArgs e)
{
    infos.Text = "Exécution en cours....";

    Task<string>.Factory
        .StartNew(
            () =>
                {
                    Thread.Sleep(500);
                    throw new InvalidOperationException("Pas cool !!!");
                    return DateTime.Now.ToString();
                })
        .ContinueWith(
            task =>
                {
                    infos.Text = task.Result;
                },
            TaskScheduler.FromCurrentSynchronizationContext());
}

Autant le dire tout de suite : ce code, c’est MAL

Si vous distribuez ce code en mode release, vos clients risquent de se retrouver face à une jolie petite fenêtre :

Pas cool. Et surtout, cette fenêtre n’apparaitra pas immédiatement au clic sur le bouton. Comme rien ne se passera immédiatement, vous pouvez avoir un utilisateur qui cliquera une dizaine de fois (ce que j’appelle CA, la “Cliquette Aigüe”) avant de voir cette fenêtre de la mort qui tue. Normalement, dans les secondes qui suivent, il vous appelle au téléphone en vous incendiant de divers mots que l’éthique m’interdit de reproduire ici (oui ils sont comme cela mes clients ).

Y’a t’il une erreur ?

La Task de la méthode ContinueWith possède heureusement une propriété IsFaulted vous indiquant si il y a eu une ou des exceptions de déclenchées dans votre code. Donc on pourrait modifier notre précédent code ainsi :

private void Button_Click(object sender, RoutedEventArgs e)
{
    infos.Text = "Exécution en cours....";

    Task<string>.Factory
        .StartNew(
            () =>
                {
                    Thread.Sleep(500);
                    throw new InvalidOperationException("Pas cool !!!");
                    return DateTime.Now.ToString();
                })
        .ContinueWith(
            task =>
                {
                    if (task.IsFaulted)
                    {
                        infos.Text = string.Format("Il y a eu des erreurs");
                    }
                    else
                    {
                        infos.Text = task.Result;
                    }
                },
            TaskScheduler.FromCurrentSynchronizationContext());
}

Mais non, cela n’est toujours pas correct. Pourquoi ? Si vous cliquez intensivement sur le bouton, vous verrez qu’à terme, votre application se plantera telle une vache tentant de faire du saut à l’élastique.

Pourquoi la vache se plantera ? Parce qu’elle ne sait pas voler !

Pourquoi votre code plantera ? Parce que le thread ne sera pas libéré. Il existera toujours une référence vers un TaskExceptionHolder qui empêchera le garbage collector de libérer votre Task, donc de supprimer le thread. Le seul moyen de le libérer correctement, est simplement d’accéder à la propriété Exception de votre Task :

private void Button_Click(object sender, RoutedEventArgs e)
{
    infos.Text = "Exécution en cours....";

    Task<string>.Factory
        .StartNew(
            () =>
                {
                    Thread.Sleep(500);
                    throw new InvalidOperationException("Pas cool !!!");
                    return DateTime.Now.ToString();
                })
        .ContinueWith(
            task =>
                {
                    if (task.IsFaulted)
                    {
                        var err = task.Exception;
                        infos.Text = string.Format("Il y a eu des erreurs : {0}", err.Message);
                    }
                    else
                    {
                        infos.Text = task.Result;
                    }
                },
            TaskScheduler.FromCurrentSynchronizationContext());
}

Cette fois ci, on tient le bon bout. Sauf que le message qui sera affiché ne sera pas le message de votre exception (“Pas cool !!!”) mais : Une ou plusieurs erreurs se sont produites.

AggregateException

En réalité, la propriété Exception de votre Task est toujours une AggregateException qui possède une propriété de type collection contenant l’ensemble des exceptions qui ont pu se produire dans votre code (votre thread peut créer d’autres threads avec des erreurs, etc.). Donc, dans notre cas ou il n’y a qu’une exception qui peut se produire, on peut accéder directement à cette exception via la propriété InnerException de l’Exception :

if (task.IsFaulted)
{
    var err = task.Exception.InnerException;
    infos.Text = string.Format("Il y a eu une erreur : {0}", err);
}
else
{
    infos.Text = task.Result;
}

AggregateException typée

Reste que si l’on écrit du code proprement, il faut utiliser le typage des exceptions.

Tout dépend comment vous avez l’habitude de gérer les exceptions, mais pour ma part, si c’est une exception à laquelle je ne m’attends pas, je fais planter l’application (je vous assure que c’est le meilleur moyen d’avoir un code “solide”).

Donc il faut gérer les exceptions auxquelles on s’attend. Pour cela, AggregateException possède une méthode Handle qui attend un prédicat. Dans ce prédicat, vous pouvez dire si vous gérez ou non l’exception déclenchée. Dans notre exemple, cela donne ceci :

if (task.IsFaulted)
{
    task.Exception.Handle(ex =>
                   {
                       if (ex.GetType() == typeof (InvalidOperationException))
                       {
                           infos.Text = "On s'y attendait à celle là";
                           return true;
                       }
                       infos.Text = "Argggg!!!";
                       return false;
                   });
}
else
{
    infos.Text = task.Result;
}

Notre prédicat retourne True pour les InvalidOperationException et False pour les autres (ca plante).

NB : AggregateException possède une méthode Flatten qui retourne une AggregateException avec un seul niveau de profondeur des exceptions.

Démarrons avec les Tasks

Tue, 14 Feb 2012 10:48:34 GMT

Que vous le vouliez ou non, le développement multi-tâche est maintenant une obligation pour toute nouvelle application. Il est donc vital d’en comprendre les mécanismes et de s’y mettre le plus tôt possible.

En attendant le .NET Framework 4.5 avec les nouveaux mots clés async et await (qui seront disponibles pour C# et VB .NET), le développement d’applications multi-thread a déjà été largement simplifié avec l’apparition de l’espace de noms System.Threading.Tasks.

Issu de travaux de Microsoft Research, Parallel FX et PLINQ ont été implémentés au coeur du framework puisque ces classes se retrouvent dans mscorlib (montrant ainsi l’importance du développement multi-tâche).

Nous allons voir dans ce premier article un premier type d’utilisation des Tasks.

Création d’une Task

Une Task est un objet qui va nous permettre d’exécuter une méthode dans un nouveau thread.

Si la méthode est une action (ie ne retourne rien), c’est la classe Task, si la méthode est une fonction (Func) et qu’elle retourne un objet de type TResult, c’est la classe générique Task<TResult> qui est utilisée.

Il y a plusieurs façons de créer une Task. La première est de tout faire “à la main”, c’est-à-dire en créant nous même l’instance de la classe, en définissant l’action ou la fonction associée, à lancer l’exécution asynchrone et à attendre le résultat. Exemple :

Console.WriteLine("1/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
var task = new Task(() =>
{
    Thread.Sleep(500);
    Console.WriteLine("2/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
});

Console.WriteLine("3/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
task.Start();

Console.WriteLine("4/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
task.Wait();
Console.WriteLine("5/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);

Ce qui donnera à la sortie :

1/ ThreadId=9
3/ ThreadId=9
4/ ThreadId=9
2/ ThreadId=10 // dans un autre Thread
5/ ThreadId=9

Je sais, ce n’est pas très lisible puisque le code 2/ qui est placé avant 3/ et 4/ est exécuté après (async/await simplifieront la lecture), mais on voit que le code de la Task est exécutée dès qu’on exécute la méthode Start et on attend son résultat grâce à Wait. (vous pouvez d’ailleurs définir le temps d’attente maximal avec Wait : Wait(TimeSpan duree)).

Une autre façon de faire (que je préfère mais cela n’engage que moi), est d’utiliser la classe TaskFactory (et son générique TaskFactory<TResult>). Cette classe possède la méthode StartNew qui fait tout le travail pour vous de création de la Task et vous retourne cette Task. Un singleton de cette classe est même accessible grâce à la propriété static de Task : Factory. On peut donc écrire :

Console.WriteLine("1/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
var task = Task.Factory.StartNew(
    (() =>
         {
             Thread.Sleep(500);
             Console.WriteLine("2/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
         }));

Console.WriteLine("3/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);

task.Wait();
Console.WriteLine("4/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);

Vous allez me dire, cela fait exactement la même chose et ce n’est pas plus lisible. Mais comme StartNew retourne la Task créée, on a accès à sa méthode ContinueWith qui est exécutée à la fin de l’action (ou de la fonction) de la Task. On peut très bien simplifier le code de la façon suivante :

Console.WriteLine("1/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
Task.Factory
    .StartNew(
        (() =>
             {
                 Thread.Sleep(500);
                 Console.WriteLine("2/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
             }))
    .ContinueWith(
        task =>
            {
                Console.WriteLine("4/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
            });

Console.WriteLine("3/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);

Ce qui donne :

1/ ThreadId=10
3/ ThreadId=10
2/ ThreadId=11 // dans un autre thread
4/ ThreadId=12 // encore un autre thread

On a donc bien l’impression d’une continuité du code.

Interaction avec l’UI

Imaginons maintenant que l’on souhaite effectuer une tâche dans un autre thread et afficher son résultat dans un textblock de notre application WPF.

J’ai donc une simple Windows WPF avec un bouton et un textblock :

<StackPanel>
    <Button Content="Clic" Click="Button_Click" />
    <TextBlock x:Name="infos"/>
</StackPanel>

Et au clic sur le bouton, je lance une tâche qui me retourne l’heure :

private void Button_Click(object sender, RoutedEventArgs e)
{
    infos.Text = "Exécution en cours…";

    Console.WriteLine("1/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);


    Task<string>.Factory
        .StartNew(
            () =>
                {
                    Thread.Sleep(500);
                    Console.WriteLine("2/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
                    return DateTime.Now.ToString();
                })
        .ContinueWith(
            task =>
                {
                    Console.WriteLine("3/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
                    infos.Text = task.Result;
                });

    Console.WriteLine("4/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
}

Et là : C’EST LE DRAME !

J’ai une exception, InvalidOperationException, m’indiquant que je n’ai pas le droit de modifier mon UI dans un autre thread que le thread principal, le thread de l’UI.

C’est tout simplement, comme nous l’avons vu plus haut, que le code exécuté dans ContinueWith n’est pas le code principal. Il faut se resynchroniser avec le thread principal.

Heureusement, Task nous permet de le faire simplement, grâce à une surcharge de ContinueWith :

private void Button_Click(object sender, RoutedEventArgs e)
{
    infos.Text = "Exécution en cours…";

    Console.WriteLine("1/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);


    Task<string>.Factory
        .StartNew(
            () =>
                {
                    Thread.Sleep(500);
                    Console.WriteLine("2/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
                    return DateTime.Now.ToString();
                })
        .ContinueWith(
            task =>
                {
                    Console.WriteLine("3/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
                    infos.Text = task.Result;
                },
            TaskScheduler.FromCurrentSynchronizationContext());

    Console.WriteLine("4/ ThreadId={0}", Thread.CurrentThread.ManagedThreadId);
}

Le TaskScheduler permet cette re-synchronisation. Simple non ?

NB : A la place de “Execution en cours…” vous pouvez faire apparaitre une petite animation pour signifier que vous êtes en train de travailler. N’oubliez pas de la faire disparaitre par la suite.

NB Bis : nous verrons dans un prochain article comment gérer les exceptions qui peuvent se produire dans notre code asynchrone.