.NET : Outils pour travailler avec le multithreading et l'asynchrone. Partie 1

Je publie sur Habr l'original de l'article dont la traduction est publiée dans l'entreprise blog.

La nécessité de faire quelque chose de manière asynchrone, sans attendre le résultat ici et maintenant, ou de diviser un gros travail entre plusieurs unités qui l'exécutent, existait même avant l'apparition des ordinateurs. Avec leur arrivée, cette nécessité est devenue très perceptible. Maintenant, en 2019, en tapant cet article sur un ordinateur portable équipé d'un processeur Intel Core à 8 cœurs, où des centaines de processus, et même plus de flux, fonctionnent simultanément. À côté, se trouve un téléphone déjà un peu usé, acheté il y a quelques années, qui a un processeur à 8 cœurs. Les ressources thématiques regorgent d'articles et de vidéos où leurs auteurs s'émerveillent des smartphones phares de cette année équipés de processeurs à 16 cœurs. MS Azure propose pour moins de 20 $/heure une machine virtuelle avec un processeur à 128 cœurs et 2 To de RAM. Malheureusement, il est impossible de tirer le maximum et de dompter cette puissance sans savoir gérer l'interaction des flux.

Terminologie

Processus (Process) — objet du système d'exploitation, espace d'adresse isolé, contient des flux.
Flux (Thread) — objet du système d'exploitation, la plus petite unité d'exécution, partie d'un processus, les flux partagent la mémoire et d'autres ressources entre eux dans le cadre du processus.
Multitâche — propriété du système d'exploitation, capacité à exécuter plusieurs processus simultanément
Multi-core — propriété d'un processeur, capacité à utiliser plusieurs cœurs pour le traitement des données
Multiprocessing — propriété d'un ordinateur, capacité à travailler simultanément avec plusieurs processeurs physiquement
Multithreading — propriété d'un processus, capacité à répartir le traitement des données entre plusieurs flux.
Parallélisme — exécution de plusieurs actions physiquement en même temps dans une unité de temps
Asynchronie — exécution d'une opération sans attendre la fin de ce traitement, le résultat de l'exécution pouvant être traité ultérieurement.

Métaphore

Toutes les définitions ne sont pas bonnes et certaines nécessitent des éclaircissements supplémentaires, donc à la terminologie formellement introduite, j'ajouterai une métaphore sur la préparation du petit déjeuner. La préparation du petit déjeuner dans cette métaphore — processus.

En préparant le petit déjeuner le matin, je (CPU) vais dans la cuisine (Ordinateur). J'ai 2 mains (Cœurs). Dans la cuisine, il y a une série d'appareils (IO): four, kettle, toaster, refrigerator. I turn on the gas, put the pan on it and pour in oil, not waiting for it to heat up (asynchronously, Non-Blocking-IO-Wait), I take eggs out of the refrigerator and crack them into a bowl, then I beat them with one hand (Thread#1), while the other (Thread#2) holds the bowl (Shared Resource). I would also turn on the kettle, but I don’t have enough hands (Thread Starvation) Meanwhile, the pan heats up (Processing the result) where I pour what I've beaten. I reach for the kettle and turn it on, just staring at the water boiling in it (Blocking-IO-Wait), even though I could have washed the bowl I used for whipping the omelet during that time.

I was making an omelet using just my 2 hands, which is all I have, but while beating the omelet, there were 3 operations going on at the same time: beating the omelet, holding the bowl, heating the pan. The CPU is the fastest part of the computer, while IO is usually what slows things down, so often an effective solution is to keep the CPU busy while waiting for data from IO.

Continuing the metaphor:

• If during the omelet cooking process, I were also trying to change clothes, that would be an example of multitasking. An important nuance: computers are much better at this than humans.
• A kitchen with several chefs, for example in a restaurant — is like a multi-core computer.
• Many restaurants on a food court in a shopping mall — is like a data center.

Tools .NET

When working with threads, as with many other things, .NET is good. With each new version, it introduces more new tools for working with them, new layers of abstraction over OS threads. When building abstractions, the framework developers employ an approach that allows the use of high-level abstractions while also being able to dive down one or more levels lower. Often, there's no need for this, moreover, it opens up the possibility of shooting oneself in the foot, but sometimes, in rare cases, it might be the only way to solve a problem not solvable at the current level of abstraction.

By tools, I mean both the APIs provided by the framework and third-party packages, as well as entire software solutions that simplify the search for any problems related to multithreaded code.

Starting a thread

La classe Thread, la plus basique dans .NET pour travailler avec des threads. Le constructeur accepte l'un des deux délégués :

• ThreadStart — Sans paramètres
• ParametrizedThreadStart — avec un paramètre de type object.

Le délégué sera exécuté dans un nouveau thread après l'appel de la méthode Start. Si un délégué de type ParametrizedThreadStart a été passé au constructeur, l'objet doit être passé à la méthode Start. Ce mécanisme est nécessaire pour transmettre toute information locale dans le thread. Il convient de noter que la création d'un thread est une opération coûteuse, et le thread lui-même est un objet lourd, ne serait-ce que parce qu'il nécessite l'allocation de 1 Mo de mémoire sur la pile et demande une interaction avec l'API du système d'exploitation.

new Thread(...).Start(...);

La classe ThreadPool représente le concept de pool. Dans .NET, le pool de threads est une œuvre d'ingénierie, et les développeurs de Microsoft ont investi un grand nombre d'efforts pour qu'il fonctionne de manière optimale dans une variété de scénarios.

Concept général :

Depuis le démarrage, l'application en arrière-plan crée plusieurs threads de réserve et permet de les utiliser. Si les threads sont souvent utilisés et en grande quantité, le pool s'étend pour répondre aux besoins du code appelant. Lorsque le pool n'a pas de threads disponibles à un moment donné, il attend le retour d'un des threads ou en crée un nouveau. Il s'ensuit que le pool de threads est très adapté pour des actions courtes et peu adapté pour des opérations fonctionnant comme des services tout au long de l'exécution des applications.

Pour utiliser un thread du pool, il existe la méthode QueueUserWorkItem, qui accepte un délégué de type WaitCallback, qui correspond à la signature de ParametrizedThreadStart, et le paramètre qui lui est passé remplit la même fonction.

ThreadPool.QueueUserWorkItem(...);

Une méthode moins connue du pool de threads, RegisterWaitForSingleObject, sert à organiser des opérations IO non bloquantes. Le délégué passé à cette méthode sera appelé lorsque le WaitHandle passé à la méthode sera "libéré".

ThreadPool.RegisterWaitForSingleObject(...)

Dans .NET, il existe un minuteur de threads, qui se distingue des minuteurs WinForms/WPF par le fait que son gestionnaire est appelé dans un thread provenant du pool.

System.Threading.Timer

Il existe également un moyen plutôt exotique d'envoyer un délégué à exécuter dans un thread du pool — la méthode BeginInvoke.

DelegateInstance.BeginInvoke

Je voudrais brièvement aborder la fonction vers laquelle se dirigent beaucoup des méthodes mentionnées ci-dessus : CreateThread de Kernel32.dll Win32 API. Il existe un moyen, grâce au mécanisme des méthodes externes, d'appeler cette fonction. Je n'ai vu un tel appel qu'une fois dans un exemple terrifiant de code legacy, et la motivation de l'auteur qui a fait cela reste pour moi un mystère.

Kernel32.dll CreateThread

Visualisation et débogage des threads

Les threads que vous avez créés vous-même, ainsi que ceux de tous les composants tiers et du pool .NET, peuvent être visualisés dans la fenêtre Threads de Visual Studio. Cette fenêtre affichera des informations sur les threads uniquement lorsque l'application sera en mode débogage et en mode d'arrêt (Break mode). Vous pouvez ici facilement visualiser la pile, les noms et les priorités de chaque thread, et basculer le débogage vers un thread spécifique. La propriété Priority de la classe Thread permet de définir la priorité du thread, qui sera perçue comme une recommandation par l'OC et le CLR lors de la répartition du temps du processeur entre les threads.

Task Parallel Library

La Task Parallel Library (TPL) est apparue dans .NET 4.0. C'est maintenant la norme et l'outil principal pour travailler avec l'asynchronisme. Tout code utilisant des approches plus anciennes est considéré comme legacy. L'unité de base de la TPL est la classe Task du namespace System.Threading.Tasks. Task représente une abstraction au-dessus du thread. Avec la nouvelle version du langage C#, nous avons obtenu une manière élégante de travailler avec des Tasks : les opérateurs async/await. Ces concepts ont permis d'écrire du code asynchrone comme s'il était simple et synchrone, ce qui a permis même à ceux qui comprennent peu le fonctionnement interne des threads d'écrire des applications qui les utilisent, sans blocage lors de longues opérations. L'utilisation d'async/await est un sujet pour un ou plusieurs articles, mais j'essaierai de résumer l'essence en quelques phrases :

• async est un modificateur de méthode qui renvoie un Task ou void
• et await est un opérateur d'attente non bloquante pour le Task.

Encore une fois : l'opérateur await, en règle générale (avec des exceptions), libérera le fil d'exécution actuel et, lorsque la tâche sera terminée, le contexte (ou plutôt, il serait plus juste de dire le contexte, mais nous y reviendrons plus tard) sera libre pour continuer l'exécution de la méthode. À l'intérieur de .NET, ce mécanisme est implémenté de la même manière que yield return, où la méthode écrite est transformée en une classe entière, qui est une machine à états et peut être exécutée par morceaux en fonction de ces états. Ceux que cela intéresse peuvent écrire un code simple en utilisant async/await, le compiler et examiner l'assemblage avec JetBrains dotPeek avec le Code généré par le compilateur activé.

Examinons les options de démarrage et d'utilisation de la tâche. À l'aide du code ci-dessous, nous créons une nouvelle tâche qui ne fait rien d'utile (Thread.Sleep(10000)), mais dans la vie réelle, cela devrait être un certain travail complexe impliquant le CPU.

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Le code de l'action sera exécuté dans un autre contexte
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    // Le code après await sera exécuté dans le contexte capturé
}

La tâche est créée avec plusieurs options :

• LongRunning — c'est une indication que la tâche ne sera pas exécutée rapidement, et il peut donc être judicieux de ne pas prendre un fil du pool, mais d'en créer un séparément pour cette tâche afin de ne pas nuire aux autres.
• AttachedToParent — les tâches peuvent être organisées en hiérarchies. Si cette option a été utilisée, la tâche peut être dans un état où elle s'est terminée et attend l'achèvement des tâches enfants.
• PreferFairness — cela signifie qu'il serait bon d'exécuter les tâches envoyées plus tôt avant celles qui ont été envoyées plus tard. Mais ce n'est qu'une recommandation et le résultat n'est pas garanti.

Le deuxième paramètre passé à la méthode est un CancellationToken. Pour traiter correctement l'annulation de l'opération après son lancement, le code exécuté doit être rempli de vérifications de l'état du CancellationToken. S'il n'y a pas de vérifications, la méthode Cancel appelée sur l'objet CancellationTokenSource ne pourra arrêter l'exécution de la tâche qu'avant son lancement.

Le dernier paramètre est un objet scheduler de type TaskScheduler. Cette classe et ses dérivés sont conçus pour gérer les stratégies de répartition des tâches sur des threads, par défaut, la tâche sera exécutée sur un thread aléatoire du pool.

Le Task créé a l'opérateur await appliqué, ce qui signifie que le code écrit après lui, s'il y en a un, sera exécuté dans le même contexte (ce qui signifie souvent sur le même thread) que le code avant await.

La méthode est marquée comme async void, ce qui signifie qu'il est permis d'utiliser l'opérateur await dans celle-ci, mais le code appelant ne pourra pas attendre l'exécution. Si cette possibilité est nécessaire, alors la méthode doit renvoyer un Task. Les méthodes marquées async void sont assez fréquentes : généralement, ce sont des gestionnaires d'événements ou d'autres méthodes qui fonctionnent selon le principe exécuter et oublier (fire and forget). Si vous devez non seulement permettre l'attente de la fin de l'exécution, mais aussi retourner un résultat, vous devez utiliser Task.

Sur le Task retourné par la méthode StartNew, comme sur n'importe quel autre, vous pouvez appeler la méthode ConfigureAwait avec le paramètre false, alors l'exécution après await continuera pas sur le contexte capturé, mais sur un arbitraire. Cela doit toujours être fait lorsque le contexte d'exécution pour le code après await n'est pas crucial. C'est également une recommandation de MS lors de l'écriture de code qui sera fourni sous forme de bibliothèque.

Arrêtons-nous un peu sur la façon d'attendre la fin de l'exécution d'un Task. Voici un exemple de code, avec des commentaires, montrant quand l'attente est faite de manière relativement correcte et quand elle est moins bonne.

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // bon

    result = AsyncMethod().Result; // mauvais

    AsyncMethod().Wait(); // mauvais

    IEnumerable tasks = new Task[] {
        AsyncMethod(), OtherAsyncMethod()
    };

    await Task.WhenAll(tasks); // bon
    await Task.WhenAny(tasks); // bon

    Task.WaitAll(tasks.ToArray()); // mauvais
}

Dans le premier exemple, nous attendons l'exécution du Task sans bloquer le thread appelant, nous reviendrons au traitement du résultat seulement lorsqu'il sera là, jusqu'à ce point, le thread appelant est libre.

Dans la deuxième option, nous bloquons le thread appelant jusqu'à ce que le résultat de la méthode soit calculé. Cela est problématique non seulement parce que nous avons occupé un thread, une ressource si précieuse pour le programme, avec une tâche inutile, mais aussi parce que si le code de la méthode que nous appelons contient un await, et que le contexte de synchronisation suppose un retour au thread appelant après l'await, nous obtiendrons un deadlock : le thread appelant attend que le résultat de la méthode asynchrone soit calculé, tandis que la méthode asynchrone essaie en vain de reprendre son exécution dans le thread appelant.

Un autre inconvénient de cette approche est la complexité accrue du traitement des erreurs. En effet, il est très facile de gérer les erreurs dans le code asynchrone utilisant async/await — elles se comportent comme si le code était synchrone. Pendant ce temps, si nous appliquons l'attente synchrone sur un Task, l'exception d'origine est enveloppée dans une AggregateException. Ainsi, pour gérer une exception, il faudra examiner le type d'InnerException et créer soi-même une chaîne de if à l'intérieur d'un bloc catch ou utiliser la construction catch when, au lieu de la chaîne de blocs catch plus habituelle dans le monde C#.

Le troisième et dernier exemple est également marqué par des défauts pour la même raison et contient tous les mêmes problèmes.

Les méthodes WhenAny et WhenAll sont extrêmement utiles pour attendre un groupe de Task, elles enveloppent un groupe de Task dans un seul qui se déclenche soit dès que l'un des Task du groupe s'exécute, soit lorsque tous ont terminé leur exécution.

Arrêt des threads

Pour diverses raisons, il peut être nécessaire d'arrêter un thread après son démarrage. Il existe plusieurs méthodes pour cela. La classe Thread propose deux méthodes aux noms appropriés — ce sont Abort et Interrupt. La première est fortement déconseillée, car après son appel, à tout moment aléatoire, dans le traitement de n'importe quelle instruction, une exception sera levée ThreadAbortedException. Vous ne vous attendez pas à ce qu'une telle exception se produise lors de l'incrémentation d'une variable entière, n'est-ce pas ? Mais avec ce méthode, c'est une situation tout à fait réaliste. Si vous devez empêcher le CLR de générer une telle exception dans une section de code, vous pouvez l'encapsuler dans des appels à Thread.BeginCriticalRegion, Thread.EndCriticalRegion. Tous les codes exécutés dans le bloc finally sont enveloppés par de tels appels. Pour cette raison, il est courant de trouver des blocs avec un try vide, mais pas un finally vide dans le code des frameworks. Microsoft déconseille tellement cette méthode qu'elle ne l'a même pas inclus dans .net core.

La méthode Interrupt fonctionne de manière plus prévisible. Elle peut interrompre un thread avec une exception. ThreadInterruptedException uniquement lorsque le thread est en état d'attente. Ce statut est atteint lorsqu'il est bloqué en attente d'un WaitHandle, lors d'un lock, ou après avoir appelé Thread.Sleep.

Les deux options décrites ci-dessus sont problématiques en raison de leur imprévisibilité. La solution consiste à utiliser la structure CancellationToken et la classe CancellationTokenSource. L'idée est la suivante : un exemplaire de la classe CancellationTokenSource est créé, et seul son propriétaire peut arrêter l'opération en appelant la méthode Cancel. Dans l'opération, seul le CancellationToken est passé. Les propriétaires du CancellationToken ne peuvent pas annuler eux-mêmes l'opération, mais peuvent seulement vérifier si elle a été annulée. Pour cela, il y a la propriété booléenne IsCancellationRequested et une méthode ThrowIfCancelRequested. Ce dernier génère une exception TaskCancelledException si la méthode Cancel a été appelée sur l'exemplaire associé au CancellationTokenSource. Et c'est précisément cette méthode que je recommande d'utiliser. Elle offre un meilleur contrôle global sur les moments où l'opération peut être interrompue par une exception.

La méthode la plus drastique pour arrêter un thread est d'appeler la fonction API Win32 TerminateThread. Le comportement du CLR après l'appel de cette fonction peut être imprévisible. Sur MSDN, il est dit à son sujet : “TerminateThread is a dangerous function that should only be used in the most extreme cases.”

Conversion de l'API legacy en méthode basée sur les tâches via la méthode FromAsync

Si vous avez eu la chance de travailler sur un projet qui a été lancé après l'introduction des tâches et qui n'a plus suscité la terreur silencieuse de la plupart des développeurs, vous n'aurez pas à gérer un grand nombre d'anciennes API, qu'elles soient tierces ou créées de manière laborieuse par votre équipe par le passé. Heureusement, l'équipe de développement de .NET Framework a pensé à nous, bien que l'objectif ait peut-être été de penser à elle-même. Quoi qu'il en soit, .NET dispose d'une série d'outils pour convertir le code écrit selon d'anciens paradigmes de programmation asynchrone en un nouveau. L'un d'eux est la méthode FromAsync de TaskFactory. Dans l'exemple de code ci-dessous, j'encapsule d'anciennes méthodes asynchrones de la classe WebRequest dans une tâche à l'aide de cette méthode.

object state = null;
WebRequest wr = WebRequest.CreateHttp("http://github.com");
await Task.Factory.FromAsync(
    wr.BeginGetResponse,
    wr.EndGetResponse
);

Ceci n'est qu'un exemple et vous n'aurez probablement pas à faire cela avec les types intégrés, mais tout ancien projet regorge de méthodes BeginDoSomething retournant un IAsyncResult et de méthodes EndDoSomething les acceptant.

Conversion des API héritées en tâche basée à l'aide de la classe TaskCompletionSource

Un autre outil important à considérer est la classe TaskCompletionSource. En termes de fonctions, d'objectifs et de fonctionnement, elle peut faire penser à la méthode RegisterWaitForSingleObject de la classe ThreadPool dont j'ai parlé précédemment. Avec cette classe, il est facile et pratique d'encapsuler d'anciennes API asynchrones dans des tâches.

Vous direz que j'ai déjà parlé de la méthode FromAsync de la classe TaskFactory destinée à ces fins. Ici, il est nécessaire de se rappeler toute l'histoire du développement des modèles asynchrones dans .NET que Microsoft a proposés au cours des 15 dernières années : avant le Task-Based Asynchronous Pattern (TAP), il y avait l'Asynchronous Programming Pattern (APP), qui traitait des méthodes BeginDoSomething retournant IAsyncResult et des méthodes EndDoSomething l'acceptant, et pour les héritages de ces années-là, la méthode FromAsync convient parfaitement, mais avec le temps, elle a été remplacée par l'Event Based Asynchronous Pattern (EAP), qui supposait qu'à la fin de l'opération asynchrone, un événement serait déclenché.

TaskCompletionSource est parfaitement adapté pour encapsuler les tâches des API héritées construites autour d'un modèle basé sur des événements. Son fonctionnement repose sur le fait que cet objet possède une propriété publique de type Task dont l'état peut être contrôlé via les méthodes SetResult, SetException, etc. Pour le classe TaskCompletionSource. Dans les endroits où l'opérateur await a été appliqué à cette tâche, elle sera exécutée ou échouera avec une exception en fonction de la méthode utilisée sur TaskCompletionSource. Si ce n'est pas encore clair, examinons cet exemple de code, où une ancienne API de l'époque de l'EAP est enveloppée dans une tâche à l'aide de TaskCompletionSource : lorsque l'événement se déclenche, la tâche sera mise dans l'état Completed, et la méthode qui a appliqué l'opérateur await à cette tâche reprendra son exécution en recevant l'objet. result.

public static Task DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    return completionSource.Task;
}

Astuces et conseils sur TaskCompletionSource

L'encapsulation des anciennes API n'est pas la seule chose que l'on peut réaliser avec TaskCompletionSource. L'utilisation de cette classe ouvre la possibilité de concevoir divers API sur des tâches, qui ne consomment pas de threads. Or, comme nous le savons, le thread est une ressource coûteuse et leur nombre est limité (principalement par la taille de la RAM). Cette limitation est facilement atteignable lors de la conception, par exemple, d'une application web fortement chargée avec une logique métier complexe. Voyons les possibilités dont je parle à travers la mise en œuvre d'un tel tour que l'on appelle Long-Polling.

En résumé, le truc est le suivant : vous devez obtenir des informations d'un API sur certains événements qui se produisent de son côté, mais pour une raison quelconque, l'API ne peut pas signaler l'événement, elle peut seulement retourner un état. Un exemple de cela serait tous les API construits au-dessus d'HTTP avant l'ère des WebSockets ou lorsque, pour une raison quelconque, cette technologie ne peut pas être utilisée. Le client peut interroger le serveur HTTP. Le serveur HTTP ne peut pas provoquer lui-même une communication avec le client. Une solution simple est de scruter le serveur avec un minuteur, mais cela entraîne une charge supplémentaire sur le serveur et un délai supplémentaire en moyenne égal à TimerInterval / 2. Pour contourner cela, un truc appelé Long Polling a été inventé, qui suppose un délai de réponse du serveur jusqu'à ce qu'un Timeout se produise ou qu'un événement se produise. Si l'événement se produit, il est traité ; sinon, la demande est renvoyée.

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

Cependant, cette solution se révélera horrible dès que le nombre de clients attendant un événement augmentera, car chaque client en attente d'un événement occupe un thread entier. De plus, cela ajoute un délai supplémentaire de 1 ms lors du déclenchement de l'événement, ce qui est souvent négligeable, mais pourquoi rendre un logiciel moins performant qu'il ne pourrait l'être ? En retirant Thread.Sleep(1), on va à l'encontre d'un cœur de processeur à 100% en tournant en boucle inutilement. Avec TaskCompletionSource, il est facile de réécrire ce code et de résoudre tous les problèmes susmentionnés :

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource> tasks;

    public async Task AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

Ce code n'est pas prêt pour la production, c'est juste une démonstration. Pour une utilisation dans des cas réels, il faut également traiter la situation où un message arrive au moment où personne ne l'attend : dans ce cas, la méthode AcceptMessageAsync doit retourner un Task déjà complété. Si ce cas s'avère être le plus fréquent, il peut être intéressant d'envisager l'utilisation de ValueTask.

Lorsqu'une demande de message est reçue, nous créons et plaçons dans un dictionnaire TaskCompletionSource, puis attendons ce qui se produira en premier : l'expiration de l'intervalle de temps défini ou la réception d'un message.

ValueTask : pourquoi et comment

Les opérateurs async/await ainsi que l'opérateur yield return génèrent une machine à états à partir de la méthode, ce qui signifie la création d'un nouvel objet, ce qui est presque toujours négligeable, mais dans de rares cas, peut poser problème. C'est le cas d'une méthode appelée très fréquemment, avec des dizaines et des centaines de milliers d'appels par seconde. Si une telle méthode est écrite de manière à renvoyer des résultats dans la plupart des cas sans passer par tous les await, .NET fournit un outil pour optimiser cela : la structure ValueTask. Pour mieux comprendre, examinons un exemple d'utilisation : il s'agit d'un cache auquel nous accédons très souvent. Si des valeurs y sont présentes, nous les renvoyons simplement, sinon nous allons chercher dans un I/O lent. Nous souhaitons effectuer cette dernière opération de manière asynchrone, ce qui rend toute la méthode asynchrone. Par conséquent, une option évidente pour écrire la méthode est la suivante :

public async Task GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return val;
    return await RequestById(id);
}

Dans le but d'optimiser un peu et par une légère inquiétude sur ce que Roslyn pourrait générer en compilant ce code, nous pouvons réécrire cet exemple comme suit :

public Task GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return Task.FromResult(val);
    return RequestById(id);
}

La solution la plus optimale dans ce cas consiste à optimiser le chemin critique, à savoir obtenir une valeur du dictionnaire sans allocations superflues ni charge sur le GC, tandis que dans les rares cas où nous devons encore accéder à l'I/O pour obtenir des données, tout se passera presque comme avant :

public ValueTask GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return new ValueTask(val);
    return new ValueTask(RequestById(id));
}

Examinons plus en détail ce fragment de code : en cas de valeur dans le cache, nous créons une structure, sinon la tâche réelle sera encapsulée dans une valeur. Le code appelant n'a pas à se soucier de la manière dont ce code est exécuté : du point de vue de la syntaxe C#, ValueTask se comportera de la même manière qu'un Task normal dans ce cas.

TaskSchedulers : gestion des stratégies de lancement des Tasks

La prochaine API que nous aimerions examiner est la classe TaskScheduler et ses dérivés. J'ai déjà mentionné ci-dessus qu'il est possible dans TPL de gérer les stratégies de distribution des tâches entre les threads. Ces stratégies sont définies dans les sous-classes de la classe TaskScheduler. Pratiquement toute stratégie nécessaire peut être trouvée dans la bibliothèque. ParallelExtensionsExtras, développée par Microsoft, mais qui ne fait pas partie de .NET, et qui est fournie sous forme de package Nuget. Examinons brièvement certaines d'entre elles :

• CurrentThreadTaskScheduler — exécute des tâches sur le thread en cours
• LimitedConcurrencyLevelTaskScheduler — limite le nombre de tâches exécutées simultanément par le paramètre N, qui est accepté dans le constructeur
• OrderedTaskScheduler — est défini comme LimitedConcurrencyLevelTaskScheduler(1), donc les tâches seront exécutées séquentiellement.
• WorkStealingTaskScheduler — implémente l'approche de 'work-stealing' pour la distribution des tâches. Il s'agit essentiellement d'un pool de threads séparé. Il résout le problème du fait que le ThreadPool dans .NET est une classe statique, unique pour toutes les applications, donc sa surcharge ou son utilisation incorrecte dans une partie du programme peut avoir des effets secondaires dans une autre partie. De plus, comprendre la cause de ces défauts est extrêmement compliqué. Ainsi, il peut y avoir un besoin d'utiliser des WorkStealingTaskSchedulers séparés dans les parties du programme où l'utilisation du ThreadPool peut être agressive et imprévisible.
• QueuedTaskScheduler — permet d'exécuter des tâches selon des règles de file d'attente avec priorités
• ThreadPerTaskScheduler — crée un thread distinct pour chaque tâche qui y est exécutée. Cela peut être utile pour des tâches dont la durée d'exécution est imprévisible.

Il existe un bon article détaillé article sur les TaskSchedulers dans le blog de Microsoft.

Pour faciliter le débogage de tout ce qui concerne les tâches dans Visual Studio, il existe une fenêtre Tasks. Dans cette fenêtre, vous pouvez voir l'état actuel de la tâche et passer à la ligne de code en cours d'exécution.

PLinq et la classe Parallel

En plus des Tasks et de tout ce qui a été dit à leur sujet dans .NET, il existe encore deux outils intéressants : PLinq (Linq2Parallel) et la classe Parallel. Le premier promet une exécution parallèle de toutes les opérations Linq sur plusieurs threads. Le nombre de threads peut être configuré à l'aide de la méthode d'extension WithDegreeOfParallelism. Malheureusement, le plus souvent, PLinq en mode par défaut ne dispose pas des informations nécessaires sur les détails internes de votre source de données pour offrir un gain de vitesse significatif. Cependant, le coût de cette tentative est très faible : il suffit d'appeler la méthode AsParallel avant la chaîne de méthodes Linq et d'effectuer des tests de performance. De plus, il est possible de transmettre à PLinq des informations supplémentaires sur la nature de votre source de données à l'aide du mécanisme Partitions. Vous pouvez lire plus de détails. ici et ici.

La classe statique Parallel fournit des méthodes pour parcourir une collection de manière parallèle avec Foreach, exécuter une boucle For et exécuter plusieurs délégués en parallèle via Invoke. L'exécution du thread actuel sera suspendue jusqu'à la fin des calculs. Le nombre de threads peut être configuré en passant ParallelOptions comme dernier argument. Grâce aux options, vous pouvez également spécifier TaskScheduler et CancellationToken.

Conclusions

Lorsque j'ai commencé à écrire cet article basé sur les matériaux de ma présentation et les informations que j'ai collectées depuis, je ne m'attendais pas à ce qu'il devienne si long. Maintenant, alors que l'éditeur de texte dans lequel je rédige cet article me dit réprimandé que j'en suis à la 15ème page, je vais tirer quelques conclusions intermédiaires. D'autres astuces, API, outils visuels et écueils seront abordés dans le prochain article.

Conclusions :

• Il est essentiel de connaître les outils pour travailler avec des threads, l'asynchronicité et le parallélisme afin d'utiliser efficacement les ressources des PC modernes.
• .NET propose de nombreux outils variés pour ces objectifs.
• Tous ne sont pas apparus en même temps, donc il est souvent possible de rencontrer des éléments legacy. Toutefois, des méthodes existent pour convertir de vieilles API sans trop d'efforts.
• Le travail avec des threads dans .NET est représenté par les classes Thread et ThreadPool.
• Les méthodes Thread.Abort, Thread.Interrupt et la fonction Win32 API TerminateThread sont dangereuses et ne sont pas recommandées. Il vaut mieux utiliser le mécanisme des CancellationTokens.
• Le flux est une ressource précieuse, leur nombre est limité. Il est nécessaire d'éviter les situations où les flux sont occupés à attendre des événements. Pour cela, il est pratique d'utiliser la classe TaskCompletionSource.
• L'outil le plus puissant et avancé de .NET pour gérer le parallélisme et l'asynchronicité est les Tasks.
• Les opérateurs C# async/await implémentent le concept d'attente non bloquante.
• La gestion de la répartition des Tasks entre les threads peut se faire à l'aide de classes dérivées de TaskScheduler.
• La structure ValueTask peut être utile pour optimiser les chemins chauds et le trafic mémoire.
• Les fenêtres Tasks et Threads de Visual Studio fournissent de nombreuses informations utiles pour le débogage du code multithread ou asynchrone.
• PLinq est un outil génial, mais il peut manquer d'informations sur votre source de données ; cependant, cela peut être corrigé grâce au mécanisme de partitionnement.
• À suivre...

Source : habr.com