Multithreading .NET: lorsque les performances font défaut

La plate-forme .NET fournit de nombreuses primitives de synchronisation prédéfinies et des collections thread-safe. Si vous devez implémenter, par exemple, un cache thread-safe ou une file d'attente de requêtes lors du développement d'une application, ces solutions prêtes à l'emploi sont généralement utilisées, parfois plusieurs à la fois. Dans certains cas, cela entraîne des problèmes de performances: une longue attente sur les verrous, une consommation de mémoire excessive et une longue récupération de place.

Ces problèmes peuvent être résolus si nous tenons compte du fait que les solutions standard sont rendues assez générales - elles peuvent avoir une surcharge dans nos scénarios qui est redondante. Par conséquent, vous pouvez écrire, par exemple, votre propre collection thread-safe efficace pour un cas spécifique.

Sous la cinématique se trouve une vidéo et une transcription de mon rapport de la conférence DotNext , où j'analyse plusieurs exemples où l'utilisation d'outils de la bibliothèque standard .NET (Task.Delay, SemaphoreSlim, ConcurrentDictionary) a conduit à des baisses de performances, et je propose des solutions adaptées à des tâches spécifiques et dépourvues de ces lacunes.


Au moment du rapport, il travaillait à Kontur. Kontur développe diverses applications pour les entreprises, et l'équipe dans laquelle j'ai travaillé s'occupe des infrastructures et développe divers services de support et bibliothèques qui aident les développeurs d'autres équipes à créer des services de produits.

L'équipe Infrastructure construit son entrepôt de données, un système d'hébergement d'applications pour Windows et diverses bibliothèques pour le développement de microservices. Nos applications sont basées sur une architecture de microservice - tous les services interagissent les uns avec les autres sur le réseau, et, bien sûr, ils utilisent beaucoup de code asynchrone et multithread. Certaines de ces applications sont très critiques en termes de performances; elles doivent être capables de gérer un grand nombre de demandes.

De quoi allons-nous parler aujourd'hui?

• Multithreading et asynchronie dans .NET;
• Remplissage des primitives et des collections de synchronisation;
• Que faire si les approches standard ne peuvent pas supporter la charge?

Analysons quelques fonctionnalités du travail avec du code multithread et asynchrone dans .NET. Examinons quelques primitives de synchronisation et collections simultanées, voyons comment elles sont organisées à l'intérieur. Nous verrons ce qu'il faut faire s'il n'y a pas suffisamment de performances, si les classes standard ne peuvent pas faire face à la charge, et si quelque chose peut être fait dans cette situation.

Je vais vous raconter quatre histoires qui se sont produites sur notre site de production.

Historique 1: Task.Delay & TimerQueue

Cette histoire est déjà assez bien connue, y compris à ce sujet lors du précédent DotNext. Cependant, il a eu une suite plutôt intéressante, alors je l'ai ajouté. Alors à quoi ça sert?

1.1 Interrogation et interrogation longue

Le serveur effectue de longues opérations, le client les attend.
Interrogation: le client interroge périodiquement le serveur sur le résultat.
Interrogation longue: le client envoie une demande avec un long délai d'expiration et le serveur répond lorsque l'opération est terminée.

Avantages:

• Moins de trafic
• Le client apprend le résultat plus rapidement

Imaginez que nous ayons un serveur capable de gérer de longues demandes, par exemple une application qui convertit des fichiers XML en PDF, et qu'il existe des clients qui exécutent ces tâches pour le traitement et souhaitent attendre leur résultat de manière asynchrone. Comment réaliser une telle attente?

La première façon est le sondage . Le client démarre la tâche sur le serveur, puis vérifie périodiquement l'état de cette tâche, tandis que le serveur renvoie l'état de la tâche ("terminée" / "échoué" / "terminée avec une erreur"). Le client envoie périodiquement des demandes jusqu'à ce que le résultat apparaisse.

La deuxième façon est le long scrutin . La différence ici est que le client envoie des demandes avec de longs délais d'attente. Le serveur, recevant une telle demande, ne signalera pas immédiatement que la tâche n'est pas terminée, mais essaiera d'attendre un certain temps pour que le résultat apparaisse.
Alors, quel est l'avantage d'un sondage long par rapport au vote régulier? Premièrement, moins de trafic est généré. Nous faisons moins de demandes sur le réseau - moins de trafic est poursuivi sur le réseau. De plus, le client pourra connaître le résultat plus rapidement qu'avec une interrogation régulière, car il n'a pas besoin d'attendre l'intervalle entre plusieurs demandes d'interrogation. Ce que nous voulons obtenir est compréhensible. Comment allons-nous implémenter cela dans le code?

Tâche: timeout
Nous voulons attendre la tâche avec un délai d'attente
attendre SendAsync ();

Par exemple, nous avons une tâche qui envoie une demande au serveur, et nous voulons attendre son résultat avec un délai d'attente, c'est-à-dire que nous retournerons le résultat de cette tâche ou enverrons une sorte d'erreur. Le code C # ressemblera à ceci:

var sendTask = SendAsync(); var delayTask = Task.Delay(timeout); var task = await Task.WhenAny(sendTask, delayTask); if (task == delayTask) return Timeout; 

Ce code lance notre tâche, dont nous voulons attendre le résultat, et Task.Delay. Ensuite, en utilisant Task.WhenAny, nous attendons notre tâche ou Task.Delay. S'il s'avère que Task.Delay est exécuté en premier, puis le temps est écoulé et nous avons un délai d'attente, nous devons renvoyer une erreur.

Ce code, bien sûr, n'est pas parfait et peut être amélioré. Par exemple, l'annulation de Task.Delay ne ferait pas de mal si SendAsync revenait plus tôt, mais ce n'est pas très intéressant pour nous maintenant. L'essentiel est que si nous écrivons un tel code et l'appliquons pour une longue interrogation avec de longs délais d'attente, nous aurons des problèmes de performances.

1.2 Problèmes liés à l'interrogation longue

• Gros délais d'attente
• De nombreuses requêtes simultanées
• => Utilisation élevée du CPU

Dans ce cas, le problème est la consommation élevée de ressources processeur. Il peut arriver que le processeur soit entièrement chargé à 100% et que l'application cesse généralement de fonctionner. Il semblerait que nous ne consommions pas du tout les ressources du processeur: nous faisons des opérations asynchrones, attendons une réponse du serveur et le processeur est toujours chargé avec nous.

Face à cette situation, nous avons supprimé un vidage de mémoire de notre application:

  ~*e!clrstack System.Threading.Monitor.Enter(System.Object) System.Threading.TimerQueueTimer.Change(…) System.Threading.Timer.TimerSetup(…) System.Threading.Timer..ctor(…) System.Threading.Tasks.Task.Delay(…) 

Pour analyser le vidage, nous avons utilisé l'outil WinDbg. Nous avons entré une commande qui affiche les traces de pile de tous les threads gérés et avons vu un tel résultat. Nous avons beaucoup de threads en cours qui attendent un verrou. La méthode Monitor.Enter est ce dans quoi la construction de verrouillage en C # se développe. Ce verrou est capturé dans des classes appelées Timer et TimerQueueTimer. Dans Timer, nous venions de Task.Delay lorsque nous avons essayé de les créer. Qu'est ce que c'est? Lorsque Task.Delay démarre, le verrou à l'intérieur de TimerQueue est capturé.

1.3 Verrouiller le convoi

• De nombreux threads essaient de verrouiller un verrou
• Sous le verrou, peu de code est exécuté
• Le temps est consacré à la synchronisation des threads, pas à l'exécution de code.
• Les blocs de threads sont bloqués - ils ne sont pas infinis

Nous avions un convoi d'écluses dans l'application. De nombreux threads tentent de capturer le même verrou. Sous ce verrou, un peu de code est exécuté. Les ressources du processeur ne sont pas dépensées ici sur le code d'application lui-même, mais sur des opérations de synchronisation entre les threads sur ce verrou. Il convient également de noter une fonctionnalité liée à .NET: les threads qui participent au convoi de verrous sont des threads du pool de threads.

Par conséquent, si les threads du pool de threads sont bloqués, ils peuvent se terminer - le nombre de threads dans le pool de threads est limité. Il peut être configuré, mais il existe toujours une limite supérieure. Une fois qu'il est atteint, tous les threads de pool de threads participeront au verrouillage du convoi et tout code impliquant le pool de threads cessera d'être exécuté dans l'application. Cela aggrave considérablement la situation.

1.4 TimerQueue

• Gère les temporisateurs dans une application .NET.
• Les minuteries sont utilisées dans:
  - Task.Delay
  - CancellationTocken.CancelAfter
  - HttpClient

TimerQueue est une classe qui gère tous les temporisateurs dans une application .NET. Si vous avez déjà programmé dans WinForms, vous avez peut-être créé des minuteurs manuellement. Pour ceux qui ne savent pas ce que sont les temporisateurs: ils sont utilisés dans Task.Delay (c'est juste notre cas), ils sont également utilisés dans CancellationToken, dans la méthode CancelAfter. En d'autres termes, le remplacement de Task.Delay par CancellationToken.CancelAfter ne nous aiderait en aucune façon. De plus, les temporisateurs sont utilisés dans de nombreuses classes internes .NET, par exemple, dans HttpClient.

Pour autant que je sache, certaines implémentations des gestionnaires HttpClient ont des temporisateurs. Même si vous ne les utilisez pas explicitement, ne démarrez pas Task.Delay, très probablement, vous les utilisez quand même.

Voyons maintenant comment TimerQueue est organisé à l'intérieur.

• État global (par domaine d'application):
  - Double liste chaînée de TimerQueueTimer
  - Verrouiller l'objet
• Rappels de minuterie de routine
• Minuteurs non classés par temps de réponse
• Ajout d'une minuterie: O (1) + verrouillage
• Retrait de la minuterie: O (1) + verrouillage
• Minuteurs de démarrage: O (N) + verrouillage

A l'intérieur de TimerQueue il y a un état global, c'est une liste doublement liée d'objets de type TimerQueueTimer. TimerQueueTimer contient un lien vers d'autres TimerQueueTimer, voisins dans une liste chaînée, il contient également l'heure de la minuterie et le rappel, qui sera appelé lorsque la minuterie se déclenche. Cette liste doublement liée est protégée par un objet de verrouillage, juste celui sur lequel le convoi de verrouillage s'est produit dans notre application. Également à l'intérieur de TimerQueue, il existe une routine qui lance des rappels liés à nos temporisateurs.

Les temporisateurs ne sont en aucun cas classés par temps de réponse, toute la structure est optimisée pour ajouter / supprimer de nouveaux temporisateurs. Lorsque Routine démarre, il parcourt toute la liste doublement liée, sélectionne les temporisateurs qui devraient fonctionner et les rappelle.

La complexité de l'opération ici est telle. L'ajout et la suppression d'une minuterie se produisent O par unité, et le démarrage des temporisateurs se produit par ligne. De plus, si tout est acceptable avec la complexité algorithmique, il y a un problème: toutes ces opérations capturent le verrou, ce qui n'est pas très bon.

Quelle situation peut arriver? Nous avons trop de temporisations accumulées dans TimerQueue, donc lorsque Routine démarre, il verrouille son long fonctionnement linéaire, à ce moment-là, ceux qui essaient de démarrer ou de supprimer des temporisations de TimerQueue ne peuvent rien y faire. Pour cette raison, le convoi d'écluse se produit. Ce problème a été corrigé dans .NET Core.

Réduire les conflits de verrouillage du minuteur (coreclr # 14527)

• Verrouillage du partitionnement
  - Environment.ProcessorCount TimerQueue's TimerQueueTimer
• Files d'attente séparées pour les temporisateurs à durée de vie courte / longue
• Minuterie courte: temps <= 1/3 seconde

https://github.com/dotnet/coreclr/issues/14462
https://github.com/dotnet/coreclr/pull/14527

Comment a-t-il été corrigé? Ils ont attaqué TimerQueue: au lieu d'un TimerQueue, qui était statique pour l'ensemble du AppDomain, pour toute l'application, plusieurs TimerQueue ont été créés. Lorsque les threads y arrivent et essaient de démarrer leurs temporisateurs, ces temporisateurs tomberont dans une TimerQueue aléatoire et les threads auront moins de chance d'entrer en collision sur un verrou.

Également dans .NET Core appliqué certaines optimisations. Les minuteries ont été divisées en longue durée et courte durée, des TimerQueue séparés sont maintenant utilisés pour elles. La minuterie de courte durée est sélectionnée pour être inférieure à 1/3 de seconde. Je ne sais pas pourquoi une telle constante a été choisie. Dans .NET Core, nous n'avons pas réussi à détecter les problèmes de temporisation.



https://github.com/Microsoft/dotnet-framework-early-access/blob/master/release-notes/NET48/dotnet-48-changes.md
https://github.com/dotnet/coreclr/labels/netfx-port-consider

Ce correctif a été rétroporté vers le .NET Framework, version 4.8. La balise netfx-port-consider est indiquée dans le lien ci-dessus, si vous allez dans le référentiel .NET Core, CoreCLR, CoreFX, vous pouvez rechercher ce problème qui sera rétroporté vers le .NET Framework, il y en a maintenant une cinquantaine. Autrement dit, le .NET open source a beaucoup aidé, quelques bugs ont été corrigés. Vous pouvez lire le journal des modifications .NET Framework 4.8: de nombreux bugs ont été corrigés, bien plus que dans les autres versions de .NET. Fait intéressant, ce correctif est désactivé par défaut dans le .NET Framework 4.8. Il est inclus dans le fichier entier que vous connaissez appelé App.config

Le paramètre dans App.config qui active ce correctif est appelé UseNetCoreTimer. Avant la sortie du .NET Framework 4.8, pour que notre application fonctionne et n'entre pas dans le convoi de verrous, vous deviez utiliser votre implémentation de Task.Delay. Dans ce document, nous avons essayé d'utiliser un tas binaire afin de comprendre plus efficacement quels temporisateurs devraient être appelés maintenant.

1.5 Task.Delay: implémentation native

• Binaryheap
• Partage
• Cela a aidé, mais pas dans tous les cas

L'utilisation d'un segment binaire vous permet d'optimiser la routine, qui appelle des rappels, mais aggrave le temps nécessaire pour supprimer un temporisateur arbitraire de la file d'attente - pour cela, vous devez reconstruire le segment. C'est probablement pourquoi .NET utilise une liste doublement liée. Bien sûr, l'utilisation d'un tas binaire ne nous aiderait pas ici, nous avons également dû travailler sur TimerQueue. Cette solution a fonctionné pendant un certain temps, mais tout est encore tombé dans le convoi de verrous en raison du fait que les minuteries sont utilisées non seulement là où elles s'exécutent explicitement dans le code, mais aussi dans les bibliothèques tierces et le code .NET. Pour résoudre complètement ce problème, vous devez mettre à niveau vers la version 4.8 de .NET Framework et activer le correctif auprès des développeurs .NET.

1.6 Délai de tâche: conclusions

• Les pièges partout - même dans les choses les plus utilisées
• Faites des tests de résistance
• Passez à Core, obtenez d'abord des corrections de bugs (et de nouveaux bugs) :)

Quelles sont les conclusions de toute cette histoire? Premièrement, les pièges peuvent être localisés vraiment partout, même dans les classes que vous utilisez tous les jours sans penser, par exemple, à la même tâche, Task.Delay.

Je recommande d'effectuer des tests de résistance de vos propositions. Ce problème que nous venons d'identifier au stade des tests de charge. Nous l'avons ensuite tourné plusieurs fois en production dans d'autres applications, mais, néanmoins, les tests de résistance nous ont aidés à retarder le temps avant de rencontrer ce problème dans la réalité.

Passez à .NET Core - vous serez le premier à recevoir des corrections de bugs (et de nouveaux bugs). Où sans nouveaux bugs?

L'histoire des minuteries est terminée et nous passons à la suivante.

Histoire 2: SemaphoreSlim

L'histoire suivante concerne le célèbre SemaphoreSlim.

2.1 Limitation du serveur

• Il est nécessaire de limiter le nombre de demandes traitées simultanément sur le serveur

Nous voulions implémenter la limitation sur le serveur. Qu'est ce que c'est Vous connaissez probablement tous l'étranglement du processeur: lorsque le processeur surchauffe, il diminue sa fréquence pour refroidir, ce qui limite ses performances. C'est donc ici. Nous savons que notre serveur peut traiter N requêtes en parallèle et ne pas tomber. Que voulons-nous faire? Limitez le nombre de demandes traitées simultanément à cette constante et faites en sorte que si plus de demandes lui parviennent, elles se mettent en file d'attente et attendent que les demandes précédentes soient exécutées. Comment résoudre ce problème? Il est nécessaire d'utiliser une sorte de primitive de synchronisation.

Semaphore est une primitive de synchronisation sur laquelle vous pouvez attendre N fois, après quoi celui qui arrive en premier N + et ainsi de suite l'attendra jusqu'à ce que ceux qui l'ont entré plus tôt libèrent Semaphore. Il s'avère quelque chose comme ceci: deux fils d'exécution, deux ouvriers sont passés sous Semaphore, les autres se sont alignés.



Bien sûr, c'est juste que Semaphore n'est pas très approprié pour nous, il est en synchronisme .NET, donc nous avons pris SemaphoreSlim et écrit ce code:

 var semaphore = new SemaphoreSlim(N); … await semaphore.WaitAsync(); await HandleRequestAsync(request); semaphore.Release(); 

Nous créons SemaphoreSlim, attendez-le, sous Semaphore nous traitons votre demande, après cela nous libérons Semaphore. Il semblerait que ce soit une implémentation idéale de la limitation du serveur, et elle ne peut plus être meilleure. Mais tout est beaucoup plus compliqué.

2.2 Limitation du serveur: complication

• Traitement des demandes dans l'ordre LIFO
• SemaphoreSlim
• Concurrentstack
• TaskCompletionSource

Nous avons un peu oublié la logique métier. Les requêtes qui aboutissent à la limitation sont de véritables requêtes http. En règle générale, ils ont un certain délai, qui est défini par ceux qui ont envoyé cette demande automatiquement, ou un délai de l'utilisateur qui appuie sur F5 après un certain temps. Par conséquent, si vous traitez les demandes dans un ordre de file d'attente, comme un sémaphore normal, tout d'abord les demandes de la file d'attente qui ont expiré peuvent déjà être traitées. Si vous travaillez dans l'ordre de la pile - traitez d'abord toutes les demandes qui sont arrivées en dernier, un tel problème ne se posera pas.

En plus de SemaphoreSlim, nous avons dû utiliser ConcurrentStack, TaskCompletionSource, pour envelopper beaucoup de code autour de tout cela, afin que tout fonctionne dans l'ordre dont nous avions besoin. TaskCompletionSource est une telle chose, qui est similaire à CancellationTokenSource, mais pas pour CancellationToken, mais pour Task. Vous pouvez créer une TaskCompletionSource, en extraire une tâche, la donner et ensuite dire à TaskCompletionSource que vous devez définir le résultat de cette tâche, et ceux qui attendent cette tâche découvriront ce résultat.

Nous l'avons tous mis en œuvre. Le code est horrible. et, pire que tout, il s'est avéré inopérant.

Quelques mois après le début de son utilisation dans une application assez chargée, nous avons rencontré un problème. De la même manière que dans le cas précédent, la consommation du processeur est passée à 100%. Nous avons fait de même, enlevé le dépotoir, regardé dans WinDbg, et retrouvé le convoi d'écluse.



Cette fois, le convoi Lock s'est produit à l'intérieur de SemaphoreSlim.WaitAsync et SemaphoreSlim.Release. Il s'est avéré qu'il y a un verrou à l'intérieur de SemaphoreSlim, il n'est pas sans verrou. Cela s'est avéré être un inconvénient assez sérieux pour nous.



À l'intérieur de SemaphoreSlim, il y a un état interne (un compteur du nombre de travailleurs qui peuvent encore y passer), et une liste doublement liée de ceux qui attendent sur ce sémaphore. Les idées ici sont à peu près les mêmes: vous pouvez attendre dans ce Sémaphore, vous pouvez annuler votre attente - quitter cette file d'attente. Il y a une serrure qui vient de ruiner nos vies.

Nous avons décidé: bas avec tout le terrible code que nous devions écrire.



Écrivons notre Sémaphore, qui sera immédiatement sans verrou et qui fonctionnera immédiatement dans l'ordre de la pile. L'annulation de l'attente n'est pas importante pour nous.



Définissez cette condition. Voici le nombre de currentCount - c'est combien plus d'espace est laissé dans le sémaphore. S'il n'y a plus de siège dans Semaphore, ce nombre sera négatif et montrera combien de travailleurs sont dans la file d'attente. Il y aura également un ConcurrentStack, composé de TaskCompletionSource'ov - c'est juste une pile de waiter'ov d'où ils seront extraits si nécessaire. Écrivons la méthode WaitAsync.

 var decrementedCount = Interlocked.Decrement(ref currentCount); if (decrementedCount >= 0) return Task.CompletedTask; var waiter = new TaskCompletionSource<bool>(); waiters.Push(waiter); return waiter.Task; 

D'abord, nous diminuons le compteur, prenons une place dans le Sémaphore pour nous-mêmes, si nous avions des places libres, et ensuite nous disons: «Ça y est, vous êtes passé sous le Sémaphore».

S'il n'y avait aucun endroit dans Semaphore, nous créons un TaskCompletionSource, le jetons sur la pile de waiter'ov et renvoyons Task au monde extérieur. Le moment venu, cette tâche fonctionnera et l'ouvrier pourra continuer son travail et passera sous Sémaphore.

Écrivons maintenant la méthode Release.

 var countBefore = Interlocked.Increment(ref currentCount) - 1; if (countBefore < 0) { if (waiters.TryPop(out var waiter)) waiter.TrySetResult(true); } 

La méthode Release est la suivante:

• Un siège gratuit dans le sémaphore
• Increment currentCount

Si nous pouvons dire par currentCount s'il y a un serveur dans la pile sur lequel nous devons signaler, nous retirons ce serveur de la pile et signalons. Ici, le serveur est un TaskCompletionSource. Question à ce code: il semble logique, mais ça marche même? Quels sont les problèmes? Il existe une nuance liée au lieu de lancement de continuation'y et TaskCompletionSource'y.



Considérez ce code. Nous avons créé un TaskCompletionSource et lancé deux tâches. La première tâche affiche une unité, définit le résultat sur un TaskCompletionSource, puis affiche un diable sur la console. La deuxième tâche attend ce TaskCompletionSource, sa tâche, puis bloque définitivement son thread du pool de threads.

Que va-t-il se passer ici? La tâche 2 lors de la compilation sera divisée en deux méthodes, la seconde étant une continuation contenant Thread.Sleep. Après avoir défini le résultat de TaskCompletionSource, cette continuation sera exécutée dans le même thread dans lequel la première tâche a été exécutée. Par conséquent, le flux de la première tâche sera bloqué pour toujours et le deuce vers la console ne sera plus imprimé.

Fait intéressant, j'ai essayé de modifier ce code, et si je supprimais la sortie de l'unité de console, la poursuite était lancée sur un autre thread du pool de threads et le diable était imprimé. Dans quels cas la suite sera exécutée dans le même thread, et dans laquelle - arrivera au pool de threads - une question pour les lecteurs.

 var tcs = new TaskCompletionSource<bool>( TaskCreationOptions.RunContinuationsAsynchronously); /* OR */ Task.Run(() => tcs.TrySetResult(true)); 

Pour résoudre ce problème, nous pouvons soit créer un TaskCompletionSource avec l'indicateur RunContinuationsAsynchronously correspondant, soit appeler la méthode TrySetResult dans Task.Run/ThreadPool.QueueUserWorkItem afin qu'il ne s'exécute pas sur notre thread. S'il est exécuté sur notre fil, nous pouvons avoir des effets secondaires indésirables. De plus, il y a un deuxième problème, nous allons nous y attarder plus en détail.



Regardez les méthodes WaitAsync et Release et essayez de trouver un autre problème dans la méthode Release.

Très probablement, de la trouver si simplement impossible. Il y a une course ici.



Cela est dû au fait que dans la méthode WaitAsync, le changement d'état n'est pas atomique. D'abord, nous décrémentons le compteur et ensuite nous poussons le serveur sur la pile. S'il arrive que Release soit exécuté entre décrémentation et push, il peut se fermer pour ne rien extraire de la pile. Cela doit être pris en compte et dans la méthode Release, attendez que le serveur apparaisse sur la pile.

 var countBefore = Interlocked.Increment(ref currentCount) - 1; if (countBefore < 0) { Waiter waiter; var spinner = new SpinWait(); while (!waiter.TryPop(out waiter)) spinner.SpinOnce(); waiter.TrySetResult(true); } 

Ici, nous le faisons en boucle jusqu'à ce que nous parvenions à le retirer. Afin de ne pas gâcher à nouveau les cycles du processeur, nous utilisons SpinWait.

Dans les premières itérations, il tournera en boucle. S'il y a beaucoup d'itérations, le serveur n'apparaîtra pas longtemps, alors notre thread ira à Thread.Sleep, afin de ne pas gaspiller à nouveau les ressources CPU.

En fait, le Sémaphore d'ordre LIFO n'est pas seulement notre idée.

LowLevelLifoSemaphore

• Synchrone
• Sous Windows utilise le port d'achèvement IO comme une pile Windows

https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/src/System/Threading/LowLevelLifoSemaphore.cs

Il existe un tel sémaphore dans .NET lui-même, mais pas dans CoreCLR, pas dans CoreFX, mais dans CoreRT. Il est parfois très utile de jeter un œil au référentiel .NET. Il existe un sémaphore appelé LowLevelLifoSemaphore. Ce sémaphore ne nous conviendrait pas de toute façon: il est synchrone.

Remarquablement, sur Windows, il fonctionne via les ports d'achèvement IO. Ils ont la propriété que les threads peuvent les attendre, et ces threads seront libérés uniquement dans l'ordre LIFO. Cette fonctionnalité y est utilisée, c'est vraiment LowLevel.

2.3 Conclusions:

• N'espérez pas que le remplissage du cadre survivra sous votre charge
• Il est plus facile de résoudre un problème spécifique que le cas général.
• Les tests de résistance n'aident pas toujours
• Attention au blocage

Quelles sont les conclusions de toute cette histoire? Tout d'abord, n'espérez pas que certaines classes du framework que vous utilisez de la bibliothèque standard supporteront votre charge. Je ne veux pas dire que SemaphoreSlim est mauvais, il s'est avéré être inadapté spécifiquement dans ce scénario.

Il s'est avéré beaucoup plus facile pour nous d'écrire notre sémaphore pour une tâche spécifique. Par exemple, il ne prend pas en charge l'annulation de l'attente. Cette fonctionnalité est disponible dans le SemaphoreSlim habituel, nous ne l'avons pas, mais cela nous a permis de simplifier le code.

Le test de charge, bien qu'il aide, peut ne pas toujours aider.

.NET , — . lock, : « ?» CPU 100%, lock', , , - .NET. .

.

3: (A)sync IO

/, .



lock convoy, stack trace Overlapped PinnableBufferCache. lock. : Overlapped PinnableBufferCache?

OVERLAPPED — Windows, /. , . , . , lock convoy. , lock convoy, , .



, , .NET 4.5.1 4.5.2. .NET 4.5.2, , .NET 4.5.2. .NET 4.5.1 OverlappedDataCache, Overlapped — , , . , lock-free, ConcurrentStack, . .NET 4.5.2 : OverlappedDataCache PinnableBufferCache.

? PinnableBufferCache , Overlapped , , — . , , . PinnableBufferCache . , lock-free, ConcurrentStack. , . , , - lock-free list lock'.

3.1 PinnableBufferCache

LockConvoy:

lock convoy , - . list , lock , , .

PinnableBufferCache , . :

 PinnableBufferCache_System.ThreadingOverlappedData_MinCount 

, . : « ! - ». -:

 Environment.SetEnvironmentVariable( "PinnableBufferCache_System.Threading.OverlappedData_MinCount", "10000"); new Overlapped().GetHashCode(); for (int i = 0; i < 3; i++) GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced); 

? , Overlapped , , . , , , , PinnableBufferCache lock convoy'. , .

.NET Core PinnableBufferCache , OverlappedData . , , Garbage collector , . .NET Core . .NET Framework, , .

3.2 :

• .NET Core

, . , .NET , . , , .NET Core. , , -.

key-value .

4: Concurrent key-value collections

.NET concurrent-. lock-free ConcurrentStack ConcurrentQueu, . ConcurrentDictionary, . lock-free , , . ConcurrentDictionary?

4.1 ConcurrentDictionary

:

Avantages:

• (TryAdd/TryUpdate/AddOrUpdate)
• Lock-free
• Lock-free enumeration

, memory-, , . , , .NET Framework. . , , (enumeration) lock-free. , .

, , - .NET. key-value - :



-, bucket'. bucket', . , bucket , .

— , ConcurrentDictionary. ConcurrentDictionary «-» . , , , memory traffic. ConcurrentDictionary, lock'. — .

, Dictionary.



Dictionary , Concurrent, . : buckets, entries. buckets bucket' entries. «-» entries. . «-» int, bucket'.

memory overhead, ConcurrentDictionary Dictionary.



Dictionary. Memory overhea' , . Dictionary overhead - , int'. 8 .

ConcurrentDictionary. ConcurrentDictionary ConcurrentDictionary.Node. , . int hashCode . , table ( 16 ), int hashCode . , 64- 28 overhead'. Dictionary.

memory overhead', ConcurrentDictionary GC , . Benchmark. ConcurrentDictionary , GC.Collect. ?



. ConcurrentDictionary 10 , , , . Dictionary . , , , . .

, ConcurrentDictionary?

4.2

• TTL
• Dictionary+lock
• Sharding

. ConcurrentDictionary. 10 . , . TTL , . Dictionary lock'. , , lock . Dictionary lock' , - , lock. , .

4.3

• in-memory <Guid,Guid>
• >10 ⁶

. — , in-memory Guid' Guid, . . - - , . , 15 . . Semaphore ConcurrentDictionary.



, lock-free , overhead GC. , . , , , . , - , , . , , Large Object Heap. ?

, , Dictionary .



Dictionary bucket', Entry. Entry , , , .



Dictionary , , . , - .

, - ? -, , , , . . Dictionary, , buckets, entries, Interlocked. , .

Dictionary

• ,
• , ?
  — Resize buckets entries
  — -
  — Dictionary.Entry
  — -

https://blogs.msdn.microsoft.com/tess/2009/12/21/high-cpu-in-net-app-using-a-static-generic-dictionary/

, Dictionary - bucket'. , . , , . , , .

Entry Dictionary. - - . , .



.NET Framework 1.1. Hashtable, Dictionary, object'. MSDN , . , -. . , Hashtable . , .

4.4 Dictionary.Entry

? Dictionary.Entry , , 8 , , , , . Comment faire

 bool writing; int version; this.writing = true; buckets[index] = …; this.version++; this.writing = false; 

: ( , ) int-. , . , , , , .

 bool writing; int version; while (true) { int version = this.version; bucket = bickets[index]; if (this.writing || version != this.version) continue; break; } 

, , . , . , 8 .

4.5 -

, .



Dictionary bucket , .

Dictionary, . : 0 2. bucket, 1 2. ? 0. , , 2. . , 2, , , 1. 1 2 — bucket. , , . 1 — , bucket. Hashtable , bucket' -. — double hashing .

4.6

Record

• , resize

La lecture

• ,

. , Buckets, Entries ( Buckets, Entries). - , , , , .

. , .

: , , , , . , , .



, , — .

? , - 2. - Capacity , . — 2. , . 2. ? , , , . - , , 3. , , , , , .

, Hashtable, . , double hashing. , , , .

, , — , . Hashtable. , — — . . , bucket', - , . .

, , lock-free LOH.



lock-free ? MSDN Hashtable , . , , .



, , , bucket'. Dictionary bucket', -, bucket' . - bucket, bucket . , .

, Large Object Heap.



. CustomDictionary CustomDictionarySegment . Dictionary, , . — Dictionary, . , Large Object Heap. , bucket' . , , , bucket, - - .

. ConcurrentDictionary, .NET, , .

4.7

• .NET
• ,

? .NET . . , , . - — - . , , , .

- , , , , . , , , , , . — , , .

Liens utiles

• ConcurrentDictionary: https://habr.com/ru/company/skbkontur/blog/348508/
• https://github.com/vostok/commons.threading
• https://github.com/epeshk/dotnext-2019-threading

— ConcurrentDictionary. , , ( Diafilm ), .

GitHub. — , , LIFO-Semaphore, . , .

6-7 DotNext 2019 Moscow «.NET: » , .NET Framework .NET Core, , .