.NET: Outils pour travailler avec le multithread et l'asynchronie - Partie 1

J'ai initialement publié cet article dans le blog CodingSight
La deuxième partie de l'article est disponible ici

La nécessité de faire les choses de manière asynchrone - c'est-à-dire de diviser les grandes tâches entre plusieurs unités de travail - était présente bien avant l'apparition des ordinateurs. Cependant, lorsqu'ils sont apparus, ce besoin est devenu encore plus évident. Nous sommes en 2019 et j'écris cet article sur un ordinateur portable alimenté par un processeur Intel Core à 8 cœurs qui, en plus de cela, travaille simultanément sur des centaines de processus, avec un nombre de threads encore plus important. À côté de moi, se trouve un smartphone légèrement obsolète que j'ai acheté il y a quelques années - et il abrite également un processeur à 8 cœurs. Les ressources Web spécialisées contiennent une grande variété d'articles faisant l'éloge des smartphones phares de cette année équipés de processeurs 16 cœurs. Pour moins de 20 $ de l'heure, MS Azure peut vous donner accès à une machine virtuelle à 128 cœurs avec 2 To de RAM. Mais, malheureusement, vous ne pouvez pas tirer le meilleur parti de ce pouvoir à moins de savoir comment contrôler l'interaction entre les threads.

Table des matières

• Terminologie
• Une métaphore
• Outils .NET
  
  • Démarrage d'un fil
  • Affichage et débogage des threads
  • Bibliothèque parallèle de tâches
  • Arrêt des threads
  • Transformer une API héritée en une API basée sur les tâches à l'aide de FromAsync
  • Transformer une API héritée en une API basée sur les tâches à l'aide de TaskCompletionSource
  • Trucs et astuces de TaskCompletionSource
  • ValueTask: pourquoi et comment
  • TaskScheduler: Contrôle des stratégies d'exécution des tâches
  • PLinq et la classe parallèle
• Résumé

Terminologie

Processus - un objet OS qui représente un espace d'adressage isolé contenant des threads.

Thread - un objet OS qui représente la plus petite unité d'exécution. Les threads sont des éléments constitutifs des processus, ils divisent la mémoire et d'autres ressources entre eux dans le cadre d'un processus.

Multitâche - une fonctionnalité du système d'exploitation qui représente la capacité d'exécuter plusieurs processus simultanément.

Multi-core - une fonction CPU qui représente la possibilité d'utiliser plusieurs cœurs pour le traitement des données

Multiprocessing - la caractéristique d'un ordinateur qui représente la capacité de travailler physiquement avec plusieurs CPU.

Multi-threading - la caractéristique d'un processus qui représente la capacité de diviser et de répartir le traitement des données entre plusieurs threads.

Parallélisme - exécution physique simultanée de plusieurs actions dans une unité de temps

Asynchronie - exécuter une opération sans attendre qu'elle soit entièrement traitée, laissant le calcul du résultat pour plus tard.

Une métaphore

Toutes les définitions ne sont pas efficaces et certaines d'entre elles nécessitent une élaboration, alors permettez-moi de fournir une métaphore culinaire pour la terminologie que je viens d'introduire.

Faire le petit déjeuner représente un processus dans cette métaphore.

En faisant le petit déjeuner le matin, je ( CPU ) vais à la cuisine ( Ordinateur ). J'ai deux mains ( noyaux ). Sur la cuisine, il y a un assortiment d'appareils ( IO ): cuisinière, bouilloire, grille-pain, réfrigérateur. J'allume le poêle, y mets une poêle et y verse de l'huile végétale. Sans attendre que l'huile se réchauffe ( asynchrone, non bloquant-IO-Wait ), je récupère des œufs du réfrigérateur, les casse sur un bol et puis je les fouette d'une main ( fil # 1 ). Pendant ce temps, la seconde main (Thread # 2) tient le bol en place ( Shared Resource ). Je voudrais allumer la bouilloire, mais je n'ai pas assez de mains libres pour le moment ( Thread Starvation ). Pendant que je fouettais les œufs, la poêle est devenue assez chaude (traitement des résultats), alors j'ai versé les œufs fouettés dedans. J'atteins la bouilloire, l'allume et regarde l'eau bouillante ( Blocking-IO-Wait ) - mais j'aurais pu utiliser cette fois pour laver le bol.

Je n'ai utilisé que 2 mains pour faire l'omelette (car je n'en ai pas plus), mais il y a eu 3 opérations simultanées en cours d'exécution: fouetter les œufs, tenir le bol, chauffer la poêle. Le CPU est la partie la plus rapide de l'ordinateur et IO est la partie qui nécessite d'attendre le plus souvent, il est donc assez efficace de charger le CPU avec du travail pendant qu'il attend les données d'IO.

Pour étendre la métaphore:

• Si j'essayais également de changer de vêtements pendant le petit-déjeuner, j'aurais été multitâche . Les ordinateurs sont bien meilleurs à cet égard que les humains.
• Une cuisine avec plusieurs cuisiniers - par exemple, dans un restaurant - est un ordinateur multicœur .
• Une aire de restauration de centre commercial avec de nombreux restaurants représenterait un centre de données .

Outils .NET

.NET est vraiment bon quand il s'agit de travailler avec des threads - ainsi qu'à bien d'autres choses. Avec chaque nouvelle version, il fournit plus d'outils pour travailler avec des threads et de nouvelles couches d'abstraction de threads OS. Lorsqu'ils travaillent avec des abstractions, les développeurs travaillant avec le framework utilisent une approche qui leur permet de descendre une ou plusieurs couches tout en utilisant des abstractions de haut niveau. Dans la plupart des cas, cela n'est pas vraiment nécessaire (et cela peut introduire une possibilité de se tirer une balle dans le pied), mais parfois, cela peut être le seul moyen de résoudre un problème qui ne peut pas être résolu au niveau d'abstraction actuel.

Lorsque j'ai parlé des outils plus tôt, je parlais à la fois des interfaces de programme (API) fournies par le cadre ou des packages tiers et des solutions logicielles à part entière qui simplifient le processus de recherche de problèmes liés au code multithread.

Démarrage d'un fil

La classe Thread est la classe .NET la plus basique pour travailler avec des threads. Son constructeur accepte l'un de ces deux délégués:

• ThreadStart - aucun paramètre
• ParametrizedThreadStart - un paramètre de type objet.

Le délégué sera exécuté dans un thread nouvellement créé après avoir appelé la méthode Start. Si le délégué ParametrizedThreadStart a été passé au constructeur, alors un objet doit être passé à la méthode Start. Ce processus est nécessaire pour transmettre toute information locale au thread. Je dois souligner qu'il faut beaucoup de ressources pour créer un thread et que le thread lui-même est un objet lourd - au moins parce qu'il nécessite une interaction avec l'API du système d'exploitation et 1 Mo de mémoire est alloué à la pile.

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

La classe ThreadPool représente le concept d'un pool. Dans .NET, le pool de threads est une œuvre d'art d'ingénierie et les développeurs Microsoft ont investi beaucoup d'efforts pour le faire fonctionner de manière optimale dans toutes sortes de scénarios.

Le concept général:
Au démarrage, l'application crée quelques threads en arrière-plan, permettant d'y accéder en cas de besoin. Si les threads sont utilisés fréquemment et en grand nombre, le pool est étendu pour répondre aux besoins du code appelant. Si le pool n'a pas suffisamment de threads libres au bon moment, il attendra que l'un des threads actifs devienne inoccupé ou en créera un nouveau. Sur cette base, il s'ensuit que le pool de threads est parfait pour les actions courtes et ne fonctionne pas si bien pour les processus qui fonctionnent comme des services pendant toute la durée de fonctionnement de l'application.

La méthode QueueUserWorkItem permet d'utiliser des threads du pool. Cette méthode prend le délégué de type WaitCallback . Sa signature coïncide avec la signature de ParametrizedThreadStart et le paramètre qui lui est transmis remplit le même rôle.

 ThreadPool.QueueUserWorkItem(...); 

La méthode de pool de threads RegisterWaitForSingleObject moins connue est utilisée pour organiser les opérations d'E / S non bloquantes. Le délégué qui est passé à cette méthode sera appelé lorsque le WaitHandle est libéré après avoir été passé à la méthode.

 ThreadPool.RegisterWaitForSingleObject(...) 

Il existe un temporisateur de threads dans .NET, et il diffère des temporisateurs WinForms / WPF en ce que son gestionnaire est appelé dans le thread extrait du pool.

 System.Threading.Timer 

Il existe également un moyen assez inhabituel d'envoyer le délégué à un thread à partir du pool - la méthode BeginInvoke.

 DelegateInstance.BeginInvoke 

Je voudrais également jeter un coup d'œil à la fonction que la plupart des méthodes que j'ai mentionnées précédemment se résument à - CreateThread de l'API Win32 Kernel32.dll. Il existe un moyen d'appeler cette fonction à l'aide du mécanisme externe des méthodes. Je n'ai vu cela être utilisé qu'une seule fois dans un cas particulièrement mauvais de code hérité - et je ne comprends toujours pas les raisons de son auteur.

 Kernel32.dll CreateThread 

Affichage et débogage des threads

Tous les threads - qu'ils soient créés par vous, des composants tiers ou le pool .NET - peuvent être affichés dans la fenêtre Threads de Visual Studio. Cette fenêtre n'affichera les informations sur les threads que lorsque l'application est en cours de débogage en mode Arrêt. Ici, vous pouvez afficher les noms et les priorités de chaque thread et concentrer le mode de débogage sur des threads spécifiques. La propriété Priority de la classe Thread vous permet de définir la priorité du thread. Cette priorité sera alors prise en considération lorsque le système d'exploitation et le CLR répartissent le temps processeur entre les threads.

Bibliothèque parallèle de tâches

La bibliothèque parallèle de tâches (TPL) est apparue pour la première fois dans .NET 4.0. Actuellement, c'est l'outil principal pour travailler avec l'asynchronie. Tout code utilisant des approches plus anciennes sera considéré comme du code hérité. L'unité principale de TPL est la classe Task de l'espace de noms System.Threading.Tasks. Les tâches représentent l'abstraction des threads. Avec la dernière version de C #, nous avons acquis une nouvelle façon élégante de travailler avec les tâches - les opérateurs asynchrones / attendent. Celles-ci permettent d'écrire du code asynchrone comme s'il était simple et synchrone, de sorte que ceux qui ne connaissent pas bien la théorie des threads peuvent désormais écrire des applications qui n'auront pas de difficulté avec de longues opérations. Utiliser async / wait est vraiment un sujet pour un article séparé (ou même quelques articles), mais je vais essayer de décrire les bases en quelques phrases:

• async est un modificateur d'une méthode qui renvoie une tâche ou un vide
• attend est un opérateur d'une tâche d'attente non bloquante.

Encore une fois: l'opérateur wait laissera généralement (il y a des exceptions) le thread courant et, lorsque la tâche sera exécutée et le thread (en fait, le contexte, mais nous y reviendrons plus tard) sera libre en tant que Par conséquent, il continuera à exécuter la méthode. Dans .NET, ce mécanisme est implémenté de la même manière que yield return - une méthode est transformée en une classe de machine à états finis qui peut être exécutée en plusieurs morceaux en fonction de son état. Si cela semble intéressant, je recommanderais d'écrire n'importe quel morceau de code simple basé sur async / wait, de le compiler et de regarder sa compilation à l'aide de JetBrains dotPeek avec le code généré par le compilateur activé.

Examinons les options dont nous disposons lorsqu'il s'agit de démarrer et d'utiliser une tâche. Dans l'exemple ci-dessous, nous créons une nouvelle tâche qui ne fait rien de productif (Thread.Sleep (10000)). Cependant, dans les cas réels, nous devons le remplacer par un travail complexe qui utilise les ressources du processeur.

 using TCO = System.Threading.Tasks.TaskCreationOptions; public static async void VoidAsyncMethod() { var cancellationSource = new CancellationTokenSource(); await Task.Factory.StartNew( // Code of action will be executed on other context () => Thread.Sleep(10000), cancellationSource.Token, TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness, scheduler ); // Code after await will be executed on captured context } 

Une tâche est créée avec les options suivantes:

• LongRunning - cette option indique que la tâche ne peut pas être effectuée rapidement. Par conséquent, il est peut-être préférable de créer un thread distinct pour cette tâche plutôt que d'en prendre un existant dans le pool pour minimiser les dommages causés aux autres tâches.
• AttachedToParent - Les tâches peuvent être organisées de manière hiérarchique. Si cette option est utilisée, la tâche attendra que ses tâches enfants soient exécutées après avoir été exécutée elle-même.
• PreferFairness - cette option spécifie que la tâche doit être mieux exécutée avant les tâches qui ont été créées ultérieurement. Cependant, c'est plus une suggestion, donc le résultat n'est pas toujours garanti.

Le deuxième paramètre transmis à la méthode est CancellationToken. Pour que l'opération soit correctement annulée après son démarrage, le code exécutable doit contenir des vérifications d'état CancellationToken. S'il n'y a pas de telles 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 le démarrage de la tâche.

Pour le dernier paramètre, nous avons envoyé un objet de type TaskScheduler appelé ordonnanceur. Cette classe, avec ses classes enfants, est utilisée pour contrôler la répartition des tâches entre les threads. Par défaut, une tâche sera exécutée sur un thread sélectionné au hasard dans le pool

L'opérateur d'attente est appliqué à la tâche créée. Cela signifie que le code écrit après (s'il existe un tel code) sera exécuté dans le même contexte (souvent, cela signifie «sur le même thread») que le code écrit avant l'attend.

Cette méthode est étiquetée comme async void, ce qui signifie que l'opérateur d'attente peut y être utilisé, mais le code appelant ne pourra pas attendre l'exécution. Si une telle possibilité est nécessaire, la méthode doit renvoyer une tâche. Les méthodes étiquetées comme async void peuvent être vues assez souvent: ce sont généralement des gestionnaires d'événements ou d'autres méthodes fonctionnant sous le principe du feu et de l'oubli. S'il est nécessaire d'attendre la fin de l'exécution et de renvoyer le résultat, vous devez utiliser Task.

Pour les tâches qui renvoient la méthode StartNew, nous pouvons appeler ConfigureAwait avec le faux paramètre - puis, l'exécution après attente se poursuivra sur un contexte aléatoire au lieu d'un contexte capturé. Cela doit toujours être fait si le code écrit après l'attente ne nécessite pas de contexte d'exécution spécifique. Il s'agit également d'une recommandation de MS lorsqu'il s'agit d'écrire du code fourni sous forme de bibliothèque.

Voyons comment nous pouvons attendre la fin d'une tâche. Ci-dessous, vous pouvez voir un exemple de code avec des commentaires indiquant quand l'attente est implémentée de manière relativement bonne ou mauvaise.

 public static async void AnotherMethod() { int result = await AsyncMethod(); // good result = AsyncMethod().Result; // bad AsyncMethod().Wait(); // bad IEnumerable<Task> tasks = new Task[] { AsyncMethod(), OtherAsyncMethod() }; await Task.WhenAll(tasks); // good await Task.WhenAny(tasks); // good Task.WaitAll(tasks.ToArray()); // bad } 

Dans le premier exemple, nous attendons que la tâche soit exécutée sans bloquer le thread appelant, nous reviendrons donc au traitement du résultat lorsqu'il sera prêt. Avant cela, le thread appelant est laissé seul.

Dans la deuxième tentative, nous bloquons le thread appelant jusqu'à ce que le résultat de la méthode soit calculé. Il s'agit d'une mauvaise approche pour deux raisons. Tout d'abord, nous gaspillons un fil - une ressource très précieuse - sur une simple attente. De plus, si la méthode que nous appelons contient une attente tandis qu'un retour au thread appelant après l'attente est prévu par le contexte de synchronisation, nous obtiendrons un blocage. Cela se produit car le thread appelant attendra le résultat d'une méthode asynchrone et la méthode asynchrone elle-même tentera sans succès de continuer son exécution dans le thread appelant.

Un autre inconvénient de cette approche est la complexité accrue de la gestion des erreurs. Les erreurs peuvent en fait être gérées assez facilement en code asynchrone si async / wait est utilisé - le processus dans ce cas est identique à celui en code synchrone. Cependant, lorsqu'une attente synchrone est appliquée à une tâche, l'exception initiale est encapsulée dans AggregateException. En d'autres termes, pour gérer l'exception, nous aurions besoin d'explorer le type InnerException et d'écrire manuellement une chaîne if dans un bloc catch ou, alternativement, d'utiliser la structure catch when au lieu de la chaîne plus habituelle de blocs catch.

Les deux derniers exemples sont également étiquetés comme relativement mauvais pour les mêmes raisons et contiennent tous les deux les mêmes problèmes.

Les méthodes WhenAny et WhenAll sont très utiles lorsqu'il s'agit d'attendre un groupe de tâches - elles regroupent ces tâches en une seule et elles seront exécutées soit lorsqu'une tâche du groupe est démarrée, soit lorsque toutes ces tâches sont exécutées avec succès.

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 façons de procéder. La classe Thread a deux méthodes avec des noms appropriés - Abort et Interruption . Je déconseille fortement d'utiliser le premier car, après son appel, il y aurait une exception ThreadAbortedException à tout moment aléatoire lors du traitement de toute instruction choisie arbitrairement. Vous ne vous attendez pas à ce qu'une telle exception se produise lorsqu'une variable entière est incrémentée, non? Eh bien, lorsque vous utilisez la méthode Abort, cela devient une réelle possibilité. Si vous devez refuser la capacité du CLR à créer de telles exceptions dans une partie spécifique du code, vous pouvez l' encapsuler dans les appels Thread. BeginCriticalRegion et Thread.EndCriticalRegion . Tout code écrit dans le bloc finally est encapsulé dans ces appels. C'est pourquoi vous pouvez trouver des blocs avec un essai vide et un non-vide enfin dans les profondeurs du code framework. Microsoft n'aime pas cette méthode au point de ne pas l'inclure dans le noyau .NET.

La méthode d' interruption fonctionne d'une manière beaucoup plus prévisible. Il peut interrompre un thread avec une ThreadInterruptedException uniquement lorsque le thread est en mode d'attente. Il passe à cet état lorsqu'il est suspendu en attendant WaitHandle, un verrou ou après l'appel de Thread.Sleep.

Ces deux méthodes présentent un inconvénient d'imprévisibilité. Pour échapper à ce problème, nous devons utiliser la structure CancellationToken et la classe CancellationTokenSource . L'idée générale est la suivante: une instance de la classe CancellationTokenSource est créée, et seuls ceux qui en sont propriétaires peuvent arrêter l'opération en appelant la méthode Cancel . Seul CancellationToken est transmis à l'opération. Les propriétaires de CancellationToken ne peuvent pas annuler l'opération eux-mêmes - ils peuvent uniquement vérifier si l'opération a été annulée. Cela peut être réalisé en utilisant une propriété booléenne IsCancellationRequested et la méthode ThrowIfCancelRequested . Le dernier générera une TaskCancelledException si la méthode Cancel a été appelée sur l'instance CancellationTokenSource qui a créé le CancellationToken. C'est la méthode que je recommande d'utiliser. Son avantage par rapport aux méthodes décrites précédemment réside dans le fait qu'il offre un contrôle total sur les cas d'exception exacts dans lesquels une opération peut être annulée.

La façon la plus brutale d'arrêter un thread serait d'appeler une fonction API Win32 appelée TerminateThread. Une fois cette fonction appelée, le comportement du CLR peut être assez imprévisible. Dans MSDN , ce qui suit est écrit sur cette fonction: «TerminateThread est une fonction dangereuse qui ne doit être utilisée que dans les cas les plus extrêmes. "

Transformer une API héritée en une API basée sur les tâches à l'aide de FromAsync

Si vous avez eu la chance de travailler sur un projet qui a été lancé après l'introduction des tâches (et lorsqu'elles n'incitent plus à l'horreur existentielle chez la plupart des développeurs), vous n'aurez pas à vous occuper des anciennes API - à la fois la tierce partie celles et ceux sur lesquels votre équipe a travaillé dans le passé. Heureusement, l'équipe de développement de .NET Framework nous a facilité la tâche - mais cela aurait pu être une prise en charge personnelle, pour tout ce que nous savons. Dans tous les cas, .NET dispose de quelques outils qui permettent de rapprocher en toute transparence le code écrit avec les anciennes approches à une forme mise à jour. L'un d'eux est la méthode TaskFactory appelée FromAsync. Dans l'exemple ci-dessous, j'encapsule les anciennes méthodes asynchrones de la classe WebRequest dans une tâche à l'aide de FromAsync.

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

Ce n'est qu'un exemple, et vous ne ferez probablement pas quelque chose de ce genre avec des types intégrés. Cependant, les anciens projets regorgent de méthodes BeginDoSomething qui renvoient les méthodes IAsyncResult et EndDoSomething qui les reçoivent.

Transformer une API héritée en une API basée sur les tâches à l'aide de TaskCompletionSource

Un autre outil à explorer est la classe TaskCompletionSource . Dans sa fonctionnalité, son objectif et son principe de fonctionnement, il ressemble à la méthode RegisterWaitForSingleObject de la classe ThreadPool que j'ai mentionnée précédemment. Cette classe nous permet d'encapsuler facilement les anciennes API asynchrones dans des tâches.

Vous voudrez peut-être dire que j'ai déjà parlé de la méthode FromAsync de la classe TaskFactory qui a servi ces objectifs. Ici, nous devons nous souvenir de l'historique complet des modèles asynchrones fournis par Microsoft au cours des 15 dernières années: avant les modèles asynchrones basés sur les tâches (TAP), il existait des modèles de programmation asynchrones (APP). Les applications étaient toutes destinées à Begin DoSomething renvoyant IAsyncResult et à la méthode End DoSomething qui l'accepte - et la méthode FromAsync est parfaite pour l'héritage de ces années. Cependant, au fil du temps, cela a été remplacé par des modèles asynchrones basés sur les événements (EAP) qui spécifiaient qu'un événement est appelé lorsqu'une opération asynchrone est exécutée avec succès.

TaskCompletionSource sont parfaits pour encapsuler des API héritées construites autour du modèle d'événement dans des tâches. Voici comment cela fonctionne: les objets de cette classe ont une propriété publique appelée Task, dont l'état peut être contrôlé par différentes méthodes de la classe TaskCompletionSource (SetResult, SetException etc.). Aux endroits où l'opérateur d'attente a été appliqué à cette tâche, il sera exécuté ou bloqué avec une exception selon la méthode appliquée à TaskCompletionSource. Pour mieux le comprendre, regardons cet exemple de code. Ici, certaines anciennes API de l'ère EAP sont enveloppées dans une tâche à l'aide de TaskCompletionSource: lorsqu'un événement est déclenché, la tâche passe à l'état Terminé tandis que la méthode qui a appliqué l'opérateur d'attente à cette tâche continue son exécution. après avoir reçu un objet résultat .

 public static Task<Result> DoAsync(this SomeApiInstance someApiObj) { var completionSource = new TaskCompletionSource<Result>(); someApiObj.Done += result => completionSource.SetResult(result); someApiObj.Do(); result completionSource.Task; } 

Trucs et astuces de TaskCompletionSource

TaskCompletionSource peut faire plus que simplement encapsuler des API obsolètes. Cette classe ouvre une possibilité intéressante de concevoir diverses API basées sur des tâches qui n'occupent pas de threads. Un thread, comme nous nous en souvenons, est une ressource coûteuse limitée principalement par la RAM. Nous pouvons facilement atteindre cette limite lors du développement d'une application Web robuste avec une logique métier complexe. Examinons les capacités que j'ai mentionnées en action en implémentant une astuce connue sous le nom de Long Polling.

En bref, voici comment fonctionne l'interrogation longue:
Vous devez obtenir des informations d'une API sur les événements qui se produisent de son côté, mais l'API, pour une raison quelconque, ne peut que renvoyer un état plutôt que de vous informer de l'événement. Un exemple serait une API construite sur HTTP avant l'apparition de WebSocket ou dans des circonstances où cette technologie ne peut pas être utilisée. Le client peut demander au serveur HTTP. Le serveur HTTP, en revanche, ne peut pas initier seul le contact avec le client. La solution la plus simple serait de demander au serveur périodiquement à l'aide d'un minuteur, mais cela créerait une charge supplémentaire pour le serveur et un délai général qui équivaut approximativement à TimerInterval / 2. Pour contourner cela, le Long Polling a été inventé. Cela implique de retarder la réponse du serveur jusqu'à l'expiration du délai d'expiration ou jusqu'à ce qu'un événement se produise. Si un événement se produit, il sera traité; sinon, la demande sera envoyée à nouveau.

 while(!eventOccures && !timeoutExceeded) { CheckTimout(); CheckEvent(); Thread.Sleep(1); } 

Cependant, l'efficacité de cette solution diminuera radicalement si le nombre de clients en attente de l'événement augmente - chaque client en attente occupe un thread complet. De plus, nous obtenons un délai supplémentaire de 1 ms pour le déclenchement d'événements. Souvent, ce n'est pas vraiment crucial, mais pourquoi rendrions-nous notre logiciel pire qu'il ne pourrait l'être? D'un autre côté, si nous supprimons Thread.Sleep (1), l'un des cœurs de processeur sera chargé à 100% sans rien faire dans un cycle inutile. Avec l'aide de TaskCompletionSource, nous pouvons facilement transformer notre code pour résoudre tous les problèmes que nous avons mentionnés:

 class LongPollingApi { private Dictionary<int, TaskCompletionSource<Msg>> tasks; public async Task<Msg> AcceptMessageAsync(int userId, int duration) { var cs = new TaskCompletionSource<Msg>(); 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); } } 

Veuillez garder à l'esprit que ce morceau de code n'est qu'un exemple, et en aucun cas prêt pour la production. Pour l'utiliser dans des cas réels, nous aurions au moins besoin d'ajouter un moyen de gérer les situations dans lesquelles un message est reçu alors que rien ne l'attendait: dans ce cas, la méthode AcceptMessageAsync devrait renvoyer une tâche déjà terminée. Si ce cas est le plus courant, nous pouvons envisager d'utiliser ValueTask.

Lors de la réception d'une demande de message, nous créons un TaskCompletionSource, le plaçons dans un dictionnaire, puis attendons l'un des événements suivants: soit l'intervalle de temps spécifié est passé, soit un message est reçu.

ValueTask: pourquoi et comment

Les opérateurs asynchrones / attendent, tout comme l'opérateur return return, génèrent une machine à états finis à partir d'une méthode, ce qui signifie créer un nouvel objet - cela n'a pas vraiment d'importance la plupart du temps, mais peut toujours créer des problèmes dans de rares cas. Un de ces cas peut se produire avec des méthodes fréquemment appelées - nous parlons de dizaines et de centaines de milliers d'appels par seconde. Si une telle méthode est écrite d'une manière qui lui fait retourner le résultat tout en contournant toutes les méthodes d'attente dans la plupart des cas, .NET fournit un outil d'optimisation pour cela - la structure ValueTask. Pour comprendre comment cela fonctionne, regardons un exemple. Supposons qu'il existe un cache auquel nous accédons régulièrement. S'il y a des valeurs, nous les renvoyons simplement; s'il n'y a pas de valeurs - nous essayons de les obtenir à partir d'un IO lent. Cette dernière devrait idéalement être effectuée de manière asynchrone, donc toute la méthode sera asynchrone. Ainsi, la façon la plus évidente d'implémenter cette méthode sera la suivante:

 public async Task<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return val; return await RequestById(id); } 

Avec un désir de l'optimiser un peu et un souci de ce que Roslyn générera lors de la compilation de ce code, nous pourrions réécrire la méthode comme ceci:

 public Task<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return Task.FromResult(val); return RequestById(id); } 

Cependant, la meilleure solution dans ce cas serait d'optimiser le hot-path - en particulier, obtenir des valeurs de dictionnaire sans allocations inutiles et sans charge sur GC. Pendant ce temps, dans les cas peu fréquents où nous devons obtenir des données d'E / S, les choses resteront presque les mêmes:

 public ValueTask<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return new ValueTask<string>(val); return new ValueTask<string>(RequestById(id)); } 

Examinons de plus près ce fragment de code: si une valeur est présente dans le cache, nous créerons une structure; sinon, la vraie tâche sera enveloppée dans une ValueTask. Le chemin par lequel ce code est exécuté n'est pas important pour le code appelant: du point de vue de la syntaxe C #, une ValueTask se comportera comme une tâche habituelle.

TaskScheduler: Contrôle des stratégies d'exécution des tâches

La prochaine API dont je voudrais parler est la classe TaskScheduler et celles qui en dérivent. J'ai déjà mentionné que TPL fournit une capacité de contrôler exactement comment les tâches sont réparties entre les threads. Ces stratégies sont définies dans des classes héritées de TaskScheduler. Presque toutes les stratégies dont nous pourrions avoir besoin se trouvent dans la bibliothèque ParallelExtensionsExtras . Cette bibliothèque est développée par Microsoft, mais ne fait pas partie de .NET - elle est plutôt distribuée sous forme de package Nuget. Voyons quelques-unes des stratégies:

• CurrentThreadTaskScheduler - exécute des tâches sur le thread actuel
• LimitedConcurrencyLevelTaskScheduler - limite le nombre de tâches exécutées simultanément en utilisant le paramètre N qu'il accepte 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 vol de travail pour l'exécution des tâches. Essentiellement, il peut être considéré comme un ThreadPool distinct. Cela aide à résoudre le problème de ThreadPool en tant que classe statique dans .NET - s'il est surchargé ou utilisé de manière incorrecte dans une partie de l'application, des effets secondaires désagréables peuvent se produire à un endroit différent. Les causes réelles de ces défauts peuvent être difficiles à localiser, vous devrez donc peut-être utiliser des WorkStealingTaskSchedulers distincts dans les parties de l'application où l'utilisation de ThreadPool peut être agressive et imprévisible.
• QueuedTaskScheduler - permet d'exécuter des tâches sur la base d'une file d'attente prioritaire
• ThreadPerTaskScheduler - crée un thread séparé pour chaque tâche qui y est exécutée. Cela peut être utile pour les tâches dont le temps d'exécution ne peut pas être estimé.

Il y a un très bon article sur TaskSchedulers sur le blog de Microsoft, alors n'hésitez pas à le consulter.

Dans Visual Studio, il existe une fenêtre Tâches qui peut vous aider à déboguer tout ce qui concerne les tâches. Dans cette fenêtre, vous pouvez voir l'état de la tâche et accéder à la ligne de code actuellement exécutée.

PLinq et la classe parallèle

Mis à part les tâches et toutes les choses qui leur sont liées, il existe deux outils supplémentaires dans .NET que nous pouvons trouver intéressants - PLinq (Linq2Parallel) et la classe Parallel . La première promet l'exécution parallèle de toutes les opérations Linq sur tous les threads. Le nombre de threads peut être configuré par une méthode d'extension WithDegreeOfParallelism. Malheureusement, dans la plupart des cas, PLinq en mode par défaut n'aura pas suffisamment d'informations sur la source de données pour fournir une augmentation significative de la vitesse. En revanche, le coût de l'essai est très faible: il suffit d'appeler AsParallel avant la chaîne de méthodes Linq et de réaliser des tests de performances. De plus, vous pouvez transmettre des informations supplémentaires sur la nature de votre source de données à PLinq en utilisant le mécanisme de partitions. Vous pouvez trouver plus d'informations ici et ici .

La classe statique Parallel fournit des méthodes pour énumérer les collections en parallèle via Foreach, exécuter le cycle For et exécuter plusieurs délégués en parallèle à Invoke. L'exécution du thread actuel sera arrêtée jusqu'à ce que les résultats soient calculés. Vous pouvez configurer le nombre de threads en passant ParallelOptions comme dernier argument. TaskScheduler et CancellationToken peuvent également être définis à l'aide d'options.

Résumé

Quand j'ai commencé à écrire cet article sur la base de ma thèse et des connaissances que j'ai acquises en travaillant après, je ne pensais pas qu'il y aurait autant d'informations. Maintenant, avec l'éditeur de texte qui me dit avec reproche que j'ai écrit près de 15 pages, je voudrais tirer une conclusion intermédiaire. Nous examinerons d'autres techniques, API, outils visuels et dangers cachés dans le prochain article.

Conclusions:

• Pour utiliser efficacement les ressources des PC modernes, vous auriez besoin de connaître les outils pour travailler avec les threads, l'asynchronie et le parallélisme.
• Il existe de nombreux outils comme celui-ci dans .NET
• Tous n'ont pas été créés en même temps, vous pouvez donc souvent rencontrer du code hérité - mais il existe des moyens de transformer les anciennes API avec peu d'effort.
• Dans .NET, les classes Thread et ThreadPool sont utilisées pour travailler avec les threads
• La méthode Thread.Abort et Thread.Interrupt, ainsi que la fonction API Win32 TerminateThread, sont dangereuses et non recommandées. Au lieu de cela, il vaut mieux utiliser CancellationTokens
• Les threads sont une ressource précieuse et leur nombre est limité. Vous devez éviter les cas dans lesquels les threads sont occupés en attendant les événements. La classe TaskCompletionSource peut aider à atteindre cet objectif.
• Les tâches sont l'outil le plus puissant et le plus robuste dont dispose NET pour travailler avec le parallélisme et l'asynchronie.
• Les opérateurs C # asynchrones / attendent implémentent le concept d'attente non bloquante
• Vous pouvez contrôler la répartition des tâches entre les threads à l'aide de classes dérivées de TaskScheduler
• La structure ValueTask peut être utilisée pour optimiser les raccourcis et le trafic mémoire
• Les fenêtres Tâches et Threads de Visual Studio fournissent de nombreuses informations utiles pour le débogage de code multithread ou asynchrone
• PLinq est un outil génial, mais il peut ne pas avoir toutes les informations requises sur votre source de données - qui peuvent toujours être corrigées avec le mécanisme de partitionnement

À suivre ...