Pourquoi le système d’exploitation a-t-il besoin / maintient des threads du kernel?

Vous trouverez ci-dessous trois modèles de threading que j’ai rencontrés. Sur la base de ces 3 architectures ci-dessous, il est nouveau pour moi de comprendre qu’il existe également quelque chose appelé thread kernel, à part le thread utilisateur introduit dans POSIX.1C.

C’est le modèle 1-1

entrez la description de l'image ici

C’est le modèle N-1.

entrez la description de l'image ici

C’est un modèle hybride.

entrez la description de l'image ici

J’ai eu beaucoup de questions sur SO pour les threads du kernel. Ce lien semble plus pertinent pour des éclaircissements.

Au niveau du processus, pour chaque processus utilisateur chargé par le chargeur Linux (par exemple), le kernel n’alloue pas le processus du kernel correspondant à l’exécution des instructions machine fournies par un processus utilisateur. Le processus utilisateur ne demande que l’exécution en mode kernel lorsqu’il nécessite une installation du module du kernel [comme malloc () / fork ()]. La planification du processus utilisateur est effectuée par le planificateur de système d’exploitation et assigne un cœur de processeur.

Par exemple, le processus utilisateur ne nécessite pas le mode d’exécution du kernel pour exécuter une instruction

a=a+2;//a is my local variable in a user level C function

Ma question:

1) Alors, quel est le but du thread au niveau du kernel? Pourquoi le système d’exploitation doit-il maintenir un thread (en plus) du kernel pour le thread utilisateur correspondant d’un processus de niveau utilisateur? Le programmeur en mode utilisateur a-t-il le contrôle sur le choix de l’un des trois modèles de threads ci-dessus pour un processus utilisateur donné via la programmation?

Après avoir compris la réponse à la première question, un complément pertinent est,

2) Le thread du kernel est-il réellement planifié par le planificateur de système d’exploitation mais pas par l’utilisateur?

Je pense que l’utilisation du mot fil de kernel est un peu trompeuse dans ces chiffres. Je connais les chiffres d’un livre sur le système d’exploitation (conception) et, si je me souviens bien, ils font référence à la façon dont le travail est planifié par le système d’exploitation. Dans les figures, chaque processus a au moins un thread de kernel atsortingbué qui est planifié par le kernel.

Le modèle N-1 montre plusieurs threads utilisateur qui ne sont pas du tout connus du kernel car ce dernier planifie le processus (ou comment il est appelé dans la figure, un seul thread du kernel ) uniquement. Donc, pour le kernel, chaque processus est un thread du kernel. Lorsque le processus se voit atsortingbuer une tranche de temps processeur, il exécute lui-même plusieurs threads en les planifiant à leur propre discrétion.

Dans le modèle 1-1 , le kernel connaît les threads utilisateur et chaque thread est pris en compte pour l’atsortingbution de temps de processeur par le planificateur. Ainsi, au lieu de planifier tout un processus, le kernel bascule entre les threads au sein des processus.

Le modèle hybride combine les deux principes, où les processus légers sont en réalité des threads connus du kernel et dont l’exécution est planifiée. De plus, ils implémentent des threads dont le kernel n’a pas connaissance et affectent du temps de processeur à l’utilisateur.

Et maintenant, pour être complètement confus, il existe en réalité un vrai thread de kernel sous Linux. Mais pour autant que je comprenne le concept, ces threads sont utilisés uniquement pour les opérations espace-kernel, par exemple lorsque les modules du kernel doivent faire les choses en parallèle.

Alors, quel est le but d’un thread au niveau du kernel?

Fournir un véhicule pour l’affectation d’un ensemble de ressources fournies par le système d’exploitation. L’ensemble comprend toujours l’exécution du code de la CPU sur un kernel. D’autres peuvent inclure un disque, une carte réseau, une base de connaissances, une souris, des timers, à la demande des appels système à partir du thread. Le kernel gère l’access à ces ressources au fur et à mesure qu’elles deviennent disponibles et arbitre entre les conflits de ressources, par exemple. une demande d’entrée de la base de connaissances lorsque aucune n’est disponible supprimera l’exécution de la CPU du thread jusqu’à ce que l’entrée de la base de connaissances devienne disponible.

Pourquoi avons-nous besoin d’un thread (en plus) du kernel pour le thread utilisateur correspondant d’un processus de niveau utilisateur?

Sans un thread de niveau kernel, le thread utilisateur ne pourrait pas obtenir d’exécution – ce serait un code mort / une stack. Notez qu’avec Linux, le concept de threads / processus peut être un peu confus, mais néanmoins, l’unité d’exécution fondamentale est un thread. Un processus est une construction de niveau supérieur dont le code doit être exécuté par au moins un thread (par exemple, celui généré par le chargeur de système d’exploitation pour exécuter le code au point d’entrée du processus lors de son premier chargement).

Le programmeur en mode utilisateur a-t-il le contrôle sur le choix de l’un des trois modèles de threads ci-dessus pour un processus utilisateur donné via la programmation?

Non, pas sans appel système, ce qui signifie quitter le mode utilisateur.

Le thread du kernel est-il réellement planifié par le planificateur de système d’exploitation, mais pas par le thread utilisateur?

Oui, c’est la seule chose qui peut être exécutée quand elle peut l’utiliser, dont l’exécution est supprimée quand elle ne le peut pas, et qui est sujette à une suppression préemptive de la CPU si le planificateur de système d’exploitation en a besoin.