Très prochainement, les 29 et 30 novembre à Saint-Pétersbourg et les 6 et 7 décembre à Moscou, nous lancerons le sixième séminaire .NET . Cette fois sur le thème du multithreading et de la compétitivité. Nous avons déjà écrit à ce sujet plusieurs fois sur Habré, mais aujourd'hui il y a une raison distincte à cela: le séminaire est une véritable exclusivité . Le fonctionnement de la primitive de synchronisation hybride sera décrit: Monitor . Oui, la petite chose familière mérite un rapport séparé. Après tout, dans son travail, il prend en compte à la fois la fréquence du processeur et le nombre de cœurs, prend en compte le verrouillage des convois / famine et est en général très compliqué.
Et à la fin de l'article de divertissement, je vous propose de passer en revue quelques QUIZ sur le multithreading.
Un petit scénario de l'atelier
La chose la plus importante qui vient du système d'exploitation est la planification des threads. Après tout, ils peuvent fonctionner à la fois en parallèle les uns avec les autres (lorsqu'ils s'exécutent actuellement sur des cœurs différents) et plus souvent (si nous parlons des mêmes threads) - séquentiellement. Après tout, le système d'exploitation ne donne pas beaucoup de temps à l'exécution - à tout le monde, après quoi il donne du temps aux autres. Le second - pour ce segment - un quantum - une quantité de temps différente peut être allouée. Par exemple, selon la version du système d'exploitation que nous utilisons: serveur ou utilisateur, si le thread d'interface utilisateur est un thread de processus avec la fenêtre active actuelle. Troisièmement, il y a des priorités et le concept «d'éviction du multitâche», lorsque votre flux, n'ayant reçu que le quantum précieux, peut le perdre, car un autre thread avec une priorité plus élevée formé. Il s'avère que notre application dépend fortement de l'environnement dans lequel elle fonctionne. Par exemple, certains services de calcul se sentiront mieux sur la version serveur du système d'exploitation (ou avec les paramètres de performances appropriés) lorsqu'il n'y a aucun autre service sur la machine: les quanta seront longs, il y aura beaucoup de temps quantique.
Mais ici une autre question se pose: si notre thread sur cette configuration établit un verrou au niveau du noyau (par exemple, Semaphore (1)), le deuxième thread arrive au verrou et entre dans ce verrou, alors il restera dans le système d'exploitation du serveur beaucoup plus longtemps qu'il ne l'était serait dans la coutume. Pourquoi? Oui, car la tranche horaire du serveur est 6 fois plus longue que celle du client et ce thread devra d'abord attendre que le premier thread atteigne le point de déverrouillage, puis lorsqu'il obtient un nouveau quantum.
Cependant, il y a de l'aide dans un tel cas: lorsque le verrou est libéré, tous les threads qui l'attendaient temporairement (par 1 quantum) ont priorité sur les autres threads et le deuxième thread recevra immédiatement le temps du processeur.
CLRium 6
Ces trois paragraphes représentent 5% du 4e rapport. Et il est déjà riche en informations utilisables à tous les niveaux: du travail avec les primitives de synchronisation au travail avec les bibliothèques de haut niveau. Et notre programme est le suivant:
- Nous examinerons les types de processus. Il y en a beaucoup, et nous en utilisons deux de force: ce sont des applications ordinaires et ModernApp;
- Trois rapports consécutifs sont des unités d'exécution au niveau du système d'exploitation: planification sur les systèmes monocœur, multicœurs et NUMA. Partout les règles sont différentes et cela doit être pris en compte dans votre travail;
- Analyse du travail des primitives de synchronisation au niveau du temps quantique. Vous avez tous appris à parler de verrouillage / Mutex / Sémaphore dans les interviews. Il est inutile de répéter, et donc nous nous armerons de chronologies et verrons comment les quanta sont répartis entre les processeurs sur toutes les primitives de synchronisation: Kernel-Space, User-Space et hybrides.
- Un véritable atelier exclusif: la structure de la primitive
Monitor . Le fait que lock(){} révélé dans try { } finally { } vous saviez déjà sans moi, mais dans quoi Monitor.Enter , Monitor.Leave , Monitor.TryEnter est Monitor.TryEnter est un sujet pour un enfer de rapport complet, dense et séparé. Croyez-moi, tout en lui est très, très cool. Il s'agit d'une primitive de synchronisation hybride conçue pour éviter la famine, le verrouillage excessif et les évasions de convois de verrouillage. - Pas moins de trois rapports solides sur le verrouillage et l'attente, y compris l'exemple des drones de reconnaissance et de la défense aérienne, essayant d'abattre ces drones. Et ces rapports ont été tellement appréciés par HighLoad ++ qu'ils ont été appelés à HighLoad ++ à Moscou le 07-08 novembre .
- Une série de rapports sur PLINQ et Async-Await. Tout est aussi détaillé que possible. Pas par heure: ce truc suffit sur Internet. Chaque technologie sera racontée "de l'intérieur": comme c'est la coutume chez CLRium.
- Et le séminaire sera clôturé par deux rapports sur la bibliothèque de collections sans verrouillage de Microsoft et Intrinsics (instructions vectorielles pour la parallélisation au niveau du processeur).
Quelques statistiques
Nous sommes le plus grand séminaire du pays et en général nous ne sommes pas une conférence simplement parce que nous aimons notre format. Vous ne choisissez pas parmi les rapports auxquels vous n'irez pas . Vous allez pour tout. En même temps, vous comprenez à l'avance que tous les sujets du séminaire vous intéressent, car le thème est un. Un nouveau record sera établi au CLRium 6: 700 personnes seront présentes dans les deux villes. Environ 700 personnes mettent leurs compétences en parallèle et travaillent avec la concurrence. Et ils iront pour des interviews. Venez et vous à nous :).