GEF 435Principes des systèmes d’exploitation

Threads Pt II(Tanenbaum 2.2)

Revue

• Décrivez les différences entre un processus et un thread

Synopsis

• Théorie d’implémentation des ThreadsEspace de l’utilisateurNoyau Implémentations hybrides

• Implémentations SpécifiqueActivations de l’ordonnanceurThreads spontanés (Pop-Up)

• Rendre le code monothread à multithread

Théorie d’implémentation des threads

• Comment les paquetages de threads sont implémentés?

• Deux places possible:Espace de l’utilisateurNoyau

• Choix est controversé: complexité vs. efficacité

Threads dans l’espace utilisateur

• Met le concept des threads entièrement dans l’espace utilisateur Le noyau ne sait rien d’eux Le noyau pense qu’il organise des processus monothread

• Structure: Les threads exécutent pardessus un système d’exécution (run-time

system) (moteur d’exécution)• Une collection de procédures qui gèrent les threads• thread_create(), thread_exit(), thread_wait(), thread_yield(), et plus...

Threads dans l’espace utilisateur

• Chaque processus a besoin d’une table de threadsSimilaire à une table de

processus, mais traque seulement:

• Compteur ordinal

• Pointeur de pile

• Registres

• État

• Table est gérée par le système d’exécution

Threads dans l’espace utilisateur

• Avantages:Permet l’implémentation de threads sur un système

d’exploitation qui ne les supporte pasTrès vite parce qu’aucune TRAP au noyau n’est

requise... L’implémentation est entièrement dans l’espace utilisateur

Chaque processus peut avoir son propre algorithme d’ordonnancement sur mesure en changeant le système d’exécution

Facile à être extensible parce que cela requiert seulement de la mémoire extra au lieu de l’espace dans le noyau pour les tables et la pile

Threads dans l’espace utilisateur

• Désavantages:Comment implémenter les appels de système bloquants?

• Si un thread appel getKey(), tout le processus va bloquer… c’est inacceptable

• Solutions incluent changer le système d’exploitation pour créer des appels non-bloquants (pas désirable) ou placer du code intervenant au tour des fonctions de bibliothèque (un jacket ou wrapper) ceci n’est pas élégant ou recommandé

Les défauts de pages sont un problème semblable aux appels de système bloquants

Threads dans l’espace utilisateur

• Désavantages:Un thread peut tourner en rond et ne jamais retourner le

contrôle au système d’exécution. C’est un problème pour un système à processus unique (pas d’interruption)

Les threads sont habituellement utilisés pour les applications où il y aura beaucoup de blocages (ie: Serveur Web)

Parce que le blocage arrive durant les appels de système• Les traps doivent être exécutées dans le noyau de toute façons.• Une fois dans le noyau pour servir l’appel, il ne demande pas

beaucoup plus de travail de changer de thread en même temps…

Threads dans le noyau

• Met le concept des threads dans le noyau

Pas besoin de moteur d’exécutionLe noyau a une table de threadsLes threads font des appels de

système pour la création/terminaison

Le noyau tient l’information des threads: registres, état, etc...

Threads dans le noyau

• Considérations de design :Tout appel qui peut bloquer un thread doit être implémenté

comme un appel de système (donc plus de fonctions dans la bibliothèque sont des appels de système). Ceci résulte en plus de temps de système (overhead!)

Quand un thread bloque, le noyau doit décider ou bien de donner le contrôle à un autre thread dans le même processus ou dans un autre processus (peut être moins désirable pour le processus qui perd sa place)

Certains systèmes n’efface pas les threads, mais les sauvegarde pour être recyclés

Threads dans le noyau

• Avantages:Beaucoup moins compliquéPas besoin de nouveau appels non-bloquantsLes défauts de page n’arrêtent pas les autres threads

dans le processus d’exécuter

• Désavantages:Les coûts d’un appel de système sont substantiels, et les

threads dans le noyau vont en demander beaucoup plus

Implémentations hybrides

• Essaie de prendre avantage des deux designsLes threads utilisateurs et noyaux sont

implémenté là où ils seront plus efficaces

Maintenant un défaut de page ne causera pas nécessairement le blocage d’un processus entier

Avantage: Le plus efficaceDésavantage: De loin la solution la

plus compliquée

Implémentations spécifiques

• Activations de l’ordonnanceurBut est de combiner la bonne performance des threads

utilisateurs avec la simplicité des threads noyauxEn particulier le système que l’on désire va:

• Les threads utilisateurs ne devraient pas avoir à faire seulement des appels non-bloquants ou avoir à vérifier si un appel va bloquer avant de faire l’appel

• Permettre à d’autres threads dans le processus d’exécuter quand un thread bloque

• Éviter les transitions inutiles entre l’espace utilisateur et noyau (ie: laisser un thread se bloquer dans le processus si il veut

en attendre un autre sans faire intervenir le noyau)

Implémentations spécifiques

• Activations de l’ordonnanceurOpération du système:

• Le noyau assigne un nombre de processeur virtuels à chaque processus

• Le système d’exécution dans l’espace utilisateur alloue des threads à ces processeurs

• Si un thread bloque sur un appel de système, le noyau fait un appel au système d’exécution (upcall) pour l’informer de quel thread a bloqué et pourquoi

• Le système d’exécution peut réordonnancer ses threads

• Plus tard un autre upcall du noyau informe le système d’exécution que le thread est de nouveau capable d’exécuter

Implémentations spécifiques

• Activations de l’ordonnanceurOpération du système:

• Les interruptions basculent encore en mode noyau. Si l’interruption n’était pas pour le processus en exécution, elle est traitée et le même thread est réactivé plus tard

• Si l’interruption était pour un thread dans le processus courrant, alors le noyau réveille le système d’exécution et le laisse décider quel thread doit exécuter

Quel est le gros problème avec ce système???• Upcalls violent le principe des systèmes en couches• Beaucoup plus difficile d’entretenir et facile de faire des

erreurs

Implémentations Spécifiques

• Threads spontanés (pop-up) La façon traditionnel de traiter les entrées dans les applications

distribuées est d’avoir un thread bloqué sur un appel de système: receive

Au lieu de cela le SE peut créer un nouveau thread quand de l’information arrive

• Vite parce que on a pas besoin de restaurer l’état du thread bloqué

• Les threads peuvent partir et exécuter dans l’espace noyau ce qui donne accès au tables dans le noyau, périphériques d’E/S, etc… VITE!

• Cependant ceci veut dire que un thread bogué pourrait faire des ravages dans le noyau...

Monothread à multithread

• Quelles sont les difficultés pour convertir un programme monothread à multithread? Variables globalesProcédures de bibliothèques non-réentrantesSignaux, comme ceux du clavierGestion de la pile

Monothread à multithread• Variables Globales

Multithreads qui utilisent les mêmes variables peuvent causer des problèmes

Monothread à multithread

• Procédures de bibliothèque non-réentrantesOn se souvient que les bibliothèques sont compilés

pour chaque programme et existent dans chaque processus (liens pour DLL)

Qu’est-ce qui arrive si une procédure assemble un message pour réseau dans une mémoire tampon et qu’un appel à cette même procédure est faite d’un autre thread?

Réparer ces problèmes peut demander la re-programmation entière de bibliothèques!

Monothread à multithread

• SignauxSi un thread demande un service du noyau, tel qu’un

alarme, comment ce signal est livré au bon thread?• Le noyau ne connaît rien des threads en mode usager!

Avec les multithreads, quel thread va avoir la notification qu’une clef a été pressée?

• PilesNormalement les piles grandissent automatiquementLe noyau ne connaît rien des piles individuelles

Quiz Time!

Questions?