La relation entre un noyau et un thread utilisateur

Question

Est-il une relation entre un noyau et un utilisateur thread?

Certains systèmes d'exploitation manuels scolaires a dit que "les cartes d'un (plusieurs) utilisateur thread à un (plusieurs) thread du noyau". Que signifie la carte signifie ici?

Answer 1

Quand ils disent que la carte, cela signifie que chaque thread du noyau est attribué à un certain nombre de mode utilisateur threads.

Kernel threads sont utilisés pour fournir des services privilégiés pour applications (telles que les appels système ). Ils sont également utilisés par le noyau pour garder une trace de ce que tout est en cours d'exécution sur le système, combien de ressources sont allouées à ce processus, et de les programmer.

Si vos applications font un usage intensif du système d'appels, plus de threads par noyau de fil, et vos applications s'exécutent plus lentement. C'est parce que le thread du noyau va devenir un goulot d'étranglement, puisque tous les appels système sera de passer à travers elle.

Sur le revers de la médaille, cependant, si vos programmes sont rarement utiliser les appels système (ou d'autres services du noyau), vous pouvez affecter un grand nombre de threads utilisateur à un thread du noyau sans trop de perte de performances, autres que les frais généraux.

Vous pouvez augmenter le nombre de threads du noyau, mais cela ajoute de la surcharge pour le noyau en général, tandis que les fils seront plus sensibles à l'égard des appels système, le système dans son ensemble deviendra plus lent.

C'est pourquoi il est important de trouver un bon équilibre entre le nombre de threads du noyau et le nombre de threads par noyau de filetage.

Answer 2

http://www.informit.com/articles/printerfriendly.aspx?p=25075

La mise en œuvre de Threads en Espace Utilisateur

Il y a deux principales façons de mettre en œuvre un package de threads: utilisateur dans l'espace et dans le noyau. Le choix est modérément controversée, et un hybride de la mise en œuvre est également possible. Nous allons maintenant décrire ces méthodes, ainsi que leurs avantages et inconvénients.

La première méthode consiste à mettre le package de threads entièrement dans l'espace utilisateur. Le noyau ne sait rien à leur sujet. Aussi loin que le noyau est concerné, il est de la gestion ordinaire, single-threaded processus. La première, et la plus évidente, l'avantage est que l'utilisateur de niveau package de threads peut être mis en œuvre sur un système d'exploitation qui ne prend pas en charge les threads. Tous les systèmes d'exploitation utilisés à tomber dans cette catégorie, et même aujourd'hui, certains continuent de le faire.

L'ensemble de ces implémentations ont la même structure générale, qui est illustrée dans la Fig. 2-8(un). Les threads s'exécutent sur un système d'exécution, qui est un ensemble de procédures permettant de gérer les threads. Nous avons vu quatre de ces déjà: thread_create, thread_exit, thread_wait, et thread_yield, mais généralement il y a plus.

Quand les fils sont gérés dans l'espace utilisateur, chaque processus a besoin de son propre thread de table pour garder une trace des threads dans ce processus. Ce tableau est analogue pour le noyau du processus de la table, sauf qu'il effectue le suivi seulement de la per-fil propriétés telles la chaque thread du compteur de programme, pointeur de pile, les registres de l'état, etc. Le fil de la table est gérée par le système d'exécution. Lorsqu'un thread est déplacé à l'état prêt ou à l'état bloqué, l'information nécessaire pour redémarrer, il est stocké dans le fil de la table, exactement de la même façon que le noyau stocke des informations sur les processus dans le processus de la table.

Lorsqu'un thread fait quelque chose qui peut l'amener à devenir bloqué localement, par exemple, en attente pour un autre thread dans son processus pour la réalisation de certains travaux, il appelle un système d'exécution de la procédure. Cette procédure vérifie pour voir si le fil doit être mis dans l'état bloqué. Si oui, il stocke le fil de registres (c'est à dire, de son propre) dans le fil de la table, regarde dans la table pour un prêt thread à exécuter, et recharge les registres de la machine avec le nouveau fil de valeurs enregistrées. Dès que le pointeur de pile et le compteur de programme ont été changé, le nouveau thread vient à la vie à nouveau automatiquement. Si la machine a une instruction pour stocker tous les registres et une autre pour les charger, tout le fil de l'interrupteur peut être fait en une poignée d'instructions. Faire fil de commutation comme c'est au moins un ordre de grandeur plus rapide que le piégeage dans le noyau et est un argument fort en faveur de niveau de l'utilisateur fils de paquets.

Cependant, il existe une différence essentielle avec les processus. Lorsqu'un thread est terminé en cours d'exécution pour le moment, par exemple, lorsqu'il appelle thread_yield, le code de thread_yield peut sauver le fil de l'information dans le fil de la table elle-même. En outre, il peut ensuite appeler le fil planificateur de choisir un autre thread à exécuter. La procédure qui permet d'économiser le fil de l'etat et le planificateur sont juste procédures locales, afin de les invoquer est beaucoup plus efficace que de faire un noyau d'appel. Parmi d'autres questions, pas de piège, pas de changement de contexte est nécessaire, la mémoire cache n'a pas besoin d'être rincé, et ainsi de suite. Cela rend la planification de thread très rapide.

Au niveau de l'utilisateur fils présentent également d'autres avantages. Ils permettent à chacun d'être son propre personnalisé algorithme d'ordonnancement. Pour certaines applications, par exemple, ceux avec un thread du garbage collector, de ne pas avoir à se soucier d'un thread d'être arrêté à un moment gênant est un plus. Ils ont aussi à l'échelle la mieux, puisque les threads du noyau auront besoin d'un certain espace de la table et de l'espace de pile dans le noyau, qui peut être un problème si il existe un très grand nombre de threads.

En dépit de leur meilleure performance, au niveau de l'utilisateur fils de paquets qui ont quelques problèmes majeurs. Le premier d'entre eux est le problème de comment bloquer les appels système sont mis en œuvre. Supposons qu'un thread lit à partir du clavier avant de toutes les clés ont été frappés. Laisser le fil en fait faire l'appel système est inacceptable, car cela va arrêter tous les threads. L'un des principaux objectifs de l'avoir threads en premier lieu pour permettre à chacun d'utiliser le blocage des appels, mais pour prévenir un thread bloqué à partir d'affecter les autres. Avec système de blocage des appels, il est difficile de voir comment cet objectif peut être atteint facilement.

Les appels système pourrait être modifié de façon à être non bloquant (par exemple, une lecture sur le clavier serait juste de retour de 0 octets si aucun des personnages étaient déjà tampon), mais nécessitant des modifications pour le système d'exploitation n'est pas attrayant. Par ailleurs, l'un des arguments en faveur de l'utilisateur au niveau de threads est précisément qu'ils pouvaient courir avec les systèmes d'exploitation existants. En outre, la modification de la sémantique de lire exigera des changements à de nombreux programmes de l'utilisateur.

Une autre alternative est possible dans le cas où il est possible de dire à l'avance si un appel de bloc. Dans certaines versions d'UNIX, un système d'appel, sélectionnez, existe, qui permet à l'appelant de dire si un éventuel la lecture de bloc. Lorsque cet appel est présent, la procédure de bibliothèque de lecture peut être remplacé par un nouveau qui d'abord fait un appel à select et alors seulement, la lecture d'appel s'il est sûr (c'est à dire, ne bloque pas). Si la lecture appel de bloc, l'appel n'est pas fait. Au lieu de cela, un autre thread est exécuté. La prochaine fois que le système d'exécution prend le contrôle, il peut vérifier à nouveau pour voir si la lecture est maintenant sûr. Cette approche nécessite la réécriture de certaines parties du système d'appel de la bibliothèque, est inefficace et peu élégante, mais il y a peu de choix. Le code placé autour de l'appel système pour effectuer la vérification est appelé une veste ou un wrapper.

Un peu analogue au problème de système de blocage des appels est le problème des défauts de page. Nous allons étudier ces Chap. 4. Pour le moment, il est suffisant de dire que les ordinateurs peuvent être mis en place de telle sorte que la totalité du programme dans la mémoire principale à la fois. Si le programme des appels ou des sauts à une instruction qui n'est pas en mémoire, un défaut de page se produit et le système d'exploitation va aller chercher le manque d'instruction (et de ses voisins) à partir du disque. Cela s'appelle une faute de page. Le processus est bloqué, tout le nécessaire à l'instruction de la localisation et de la lire dans. Si un thread entraîne un défaut de page, le noyau, même pas connaître l'existence de threads, naturellement bloque tout le processus jusqu'à ce que le disque I/O est complète, même si d'autres threads peut être exécutable.

Un autre problème au niveau de l'utilisateur fil des paquets est que si un thread commence à courir, aucun autre thread dans le processus sera exécuté à moins que le premier thread donne volontairement le CPU. Au sein d'un processus unique, il n'y a pas des interruptions d'horloge, le rendant impossible à planifier des processus "round-robin" (compte tours). Sauf si un fil entre le système d'exécution de son propre libre arbitre, le planificateur n'obtiendrez jamais une chance.

Une solution possible au problème de threads en cours d'exécution pour toujours c'est d'avoir le système d'exécution demande un signal d'horloge (interruption) une fois de plus une seconde à lui donner le contrôle, mais cela, aussi, est brut et désordonné de programme. Périodique des interruptions d'horloge à une fréquence plus élevée ne sont pas toujours possible, et même s'ils le sont, le total des coûts indirects peuvent être substantiels. En outre, un thread peut aussi avoir besoin d'une horloge, d'interrompre, d'entraver l'exécution du système d'utilisation de l'horloge.

De l'autre, et probablement le plus dévastateur de l'argument contre au niveau de l'utilisateur fils, est que les programmeurs veulent généralement threads précisément dans les applications où les blocs de threads souvent, comme, par exemple, un serveur Web multi-threadé. Ces fils sont constamment effectuer des appels système. Une fois un piège a eu lieu vers le noyau pour réaliser l'appel système, il n'est plus guère de travail pour que le noyau fils de l'interrupteur si l'ancien a bloqué, et d'avoir le noyau cela élimine le besoin de constamment sélectionnez appels système vérifier pour voir si lire les appels système sont en sécurité. Pour les applications qui sont essentiellement entièrement en CPU, et rarement bloc, ce qui est le point d'avoir des fils à tous? Sans un serait gravement proposer le calcul des n premiers nombres premiers ou à jouer aux échecs en utilisant des fils car il n'y a rien à gagner à faire de cette façon.

Answer 3

Threads utilisateur sont gérés dans l'espace utilisateur - à-dire la planification, de la commutation, etc. ne sont pas du noyau.

Car, en fin de compte, le noyau du système d'exploitation est responsable de la commutation de contexte entre les "unités d'exécution" - votre threads utilisateur doit être associé (ie., "la carte") pour un noyau de préférence d'heure de l'objet - un thread du noyau[+1].

Donc, étant donné N threads utilisateur - vous pouvez utiliser N threads du noyau (1:1 carte). Qui vous permet de profiter du noyau du matériel multi-processing (en cours d'exécution sur plusieurs Processeurs) et être un peu simpliste de la bibliothèque - fondamentalement, il suffit de reporter la plupart du travail pour le noyau. Toutefois, elle permet de rendre votre application portable entre les OS, comme vous n'êtes pas directement en appelant le noyau de filetage fonctions. Je crois que les Threads POSIX (PThreads) est le préféré *nix mise en œuvre, et qu'il suit la correspondance 1:1 (ce qui les rend pratiquement équivalent à un thread du noyau). Qui, cependant, n'est pas garanti que ce serait dépendant de l'implémentation (une des raisons principales pour l'utilisation de PThreads serait la portabilité entre les grains).

Ou, vous pouvez utiliser seulement 1 thread du noyau. Que feriez vous permettre de courir sur la non OS multitâche, ou être complètement en charge de la planification. Windows [Utilisateur de Planification de Mode] est un exemple de cette N:1 carte.

Ou, vous pourrait correspondre à un nombre arbitraire de threads du noyau - un N:M carte. Windows a de Fibres, ce qui vous permettra de la carte N fibres de M threads du noyau et en collaboration, de les planifier. Un pool de threads pourrait également être un exemple de ce - N workitems pour M threads.

[+1] Un processus possède au moins 1 thread du noyau, qui est l'unité d'exécution. Aussi, un thread du noyau doivent être contenues dans un processus. Les OS doivent fixer le fil à l'exécution et non pas le processus.

Answer 4

• C'est une question à propos de la bibliothèque de threads mettre en œuvre.
• Sous Linux, un thread (ou la tâche) pourrait être dans l'espace utilisateur ou dans l'espace du noyau. L'entrée dans l'espace du noyau lorsqu'on demande noyau de faire quelque chose par syscall(lire, écrire ou ioctl).
• Il est aussi appelé kernel thread qui s'exécute toujours dans l'espace du noyau et ne constituent en aucun processus utilisateur.

Answer 5

Selon Wikipedia et Oracle, au niveau de l'utilisateur fils sont en fait dans une couche monté sur les threads du noyau; pas que les threads du noyau exécuter les côtés au niveau de l'utilisateur fils, mais que, de façon générale, les seules entités qui sont effectivement exécutées par le processeur/OS sont des threads du noyau.

Par exemple, supposons que nous avons un programme avec 2 niveau de l'utilisateur fils, tous deux mappée (c'est à dire affecté) le même thread du noyau. Parfois, le thread du noyau exécute la première au niveau de l'utilisateur thread (et il est dit qu' actuellement ce thread du noyau est associé à la première au niveau de l'utilisateur thread) et quelques autres fois le thread du noyau exécute le deuxième niveau de l'utilisateur thread. Donc, nous disons que nous avons deux au niveau de l'utilisateur fils mappé sur le même thread du noyau.

Comme une clarification:

Le noyau d'un système d'exploitation est appelé de son noyau, de sorte que les fils au niveau du noyau (c'est à dire les threads du noyau connaît et gère) sont appelés threads du noyau, les appels à l'OS de base pour les services peut être appelé noyau appels, et ... . La seule relation entre le noyau des choses , c'est qu'ils sont fortement liés à l'OS de base, rien de plus.