La société Google Pour intégrer dans le noyau Linux le premier ensemble de correctifs implémentant les composants nécessaires au fonctionnement du modèle de threads M:N. L'initiative de Google est liée à l'ouverture d'une API développée dans l'ombre. Pour le noyau Linux, permettant le fonctionnement d'une sous-système multithread mise en œuvre dans l'espace utilisateur, utilisant le modèle de threads M:N. Ce sous-système est utilisé par Google pour faire fonctionner des services nécessitant des latences minimales. La planification et la gestion de la distribution des threads se font entièrement dans l'espace utilisateur, ce qui permet de réduire considérablement le nombre d'opérations de changement de contexte en minimisant l'exécution des appels système.
Pour assurer le fonctionnement de ce sous-système au niveau du noyau Linux, une API SwitchTo a été mise en œuvre, offrant trois opérations de base : wait, resume et swap (changement). Pour intégrer dans le noyau, un nouveau code d'opération FUTEX_SWAP a été proposé, complémentant , et fournissant une base pour la création de bibliothèques multithread dans l'espace utilisateur. FUTEX_SWAP peut également être utilisé pour transmettre des messages entre tâches, similaire à RPC. Par exemple, actuellement pour transmettre un message entre tâches, il faut au moins effectuer quatre appels FUTEX_WAIT et FUTEX_WAKE, tandis que l'utilisation de FUTEX_SWAP permettra d'effectuer une seule opération, qui sera réalisée 5 à 10 fois plus vite.
Actuellement, dans la pratique, les modèles de threads 1:1 et N:1 sont principalement utilisés. Le modèle 1:1 est utilisé dans (threads POSIX) et , et implique une correspondance directe entre un thread dans l'espace utilisateur et un thread (une unité de planification d'exécution) au niveau du noyau. Le modèle N:1 est implémenté dans , déportant la répartition des threads dans l'espace utilisateur et permettant à N threads dans l'espace utilisateur d'être liés à un seul thread dans le noyau, celui-ci n'ayant pas d'informations sur les threads utilisateur.
Le principal inconvénient du modèle 1:1 est le coût élevé de la commutation de contexte entre le noyau et l'espace utilisateur. Le modèle N:1 résout ce problème, mais en crée un nouveau : comme un flux dans le noyau est une unité indivisible de planification d'exécution, les flux utilisateurs liés à un flux dans le noyau du système d'exploitation ne peuvent pas se répartir sur plusieurs cœurs CPU et se retrouvent liés à un seul cœur CPU.
Le modèle M:N est hybride et élimine tous les inconvénients mentionnés ci-dessus grâce à l'appariement de N flux dans l'espace utilisateur avec M flux dans le noyau OS, ce qui permet de réduire à la fois le coût de la commutation de contexte et d'assurer une répartition sur les cœurs CPU. Le prix à payer pour cette solution est un complexité accrue dans la mise en œuvre de l'ordonnanceur de flux dans l'espace utilisateur et la nécessité de mécanismes de coordination des actions avec l'ordonnanceur du noyau.
Source : opennet.ru
