Linux utilise un modèle de thread un-à-un, et la différence entre le changement de thread utilisateur et le changement de thread du noyau est très faible. Dans le même temps, si vous ignorez la surcharge causée par l'abandon volontaire par l'utilisateur des droits d'exécution (rendement) du thread utilisateur, il vous suffit de prendre en compte la surcharge liée au changement de thread du noyau. (Apprentissage recommandé : tutoriel Linux)
Notez qu'il ne s'agit que d'une simplification pour aider à la compréhension. En fait, la bibliothèque de threads utilisateur effectue beaucoup de travail dans la planification et la synchronisation des threads utilisateur, et ce coût ne peut être ignoré.
Comme l'explique la JVM Thread#yield() : Si le système d'exploitation sous-jacent ne prend pas en charge la sémantique de rendement, la JVM laissera le thread utilisateur tourner jusqu'à la fin de la tranche de temps, et le thread sera passivement commuté pour obtenir un effet similaire.
Qu'est-ce qui cause le changement de thread
Rotation des tranches de temps
Blocage des threads
Le thread abandonne activement la tranche de temps
Surcharge directe
La surcharge directe est causée par le changement de thread lui-même, ce qui est inévitable et inévitable.
Basculer entre le mode utilisateur et le mode noyau
Le changement de thread ne peut être effectué qu'en mode noyau. Si l'utilisateur actuel est en mode utilisateur, cela provoquera inévitablement un conflit. entre le mode utilisateur et le mode noyau. (Quel est le coût spécifique du "basculement entre le mode utilisateur et le mode noyau"???)
Changement de contexte
Comme mentionné précédemment, les informations sur le thread (ou le processus, quel que soit le nom que vous lui donnez) doivent être enregistrées dans une task_struct Lors du changement de thread, il est nécessaire de supprimer la task_struct de l'ancien thread du noyau et de l'insérer. le nouveau fil de discussion, provoquant un changement de contexte. De plus, il est également nécessaire de changer de registre, de compteur de programme, de pile de threads (y compris les piles d'opérations, les piles de données), etc.
Algorithme de planification des threads
L'algorithme de planification des threads doit gérer l'état des threads, les conditions d'attente, etc. S'il est planifié en fonction de la priorité, il doit également maintenir une file d'attente prioritaire. Si le changement de thread est fréquent, ce coût ne peut être sous-estimé.
Surcharge indirecte
La surcharge indirecte est un effet secondaire de la surcharge directe et dépend de la mise en œuvre du système et de la mise en œuvre du code utilisateur.
Cache manquant
Processus de changement, une nouvelle logique doit être exécutée. Si les espaces d'adressage accessibles par les deux ne sont pas similaires, des échecs de cache se produiront. L'impact spécifique dépend de l'implémentation du système et de l'implémentation du code utilisateur. Si le cache du système est plus grand, l'impact des échecs de cache peut être réduit ; si les espaces d'adressage dans lesquels les threads utilisateur accèdent aux données sont proches les uns des autres, le taux d'échecs de cache lui-même sera également relativement faible.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!