Threads et Lightweight Processes Chapitre 5 En français on utilise souvent ‘fils’ pour ‘threads’. Le manuel que je suis préfère le mot anglais thread: qui est la terminologie Java http://w3.uqo.ca/luigi/

Concepts importants du Chap. 5 Threads et processus: différence Threads de noyau et d’usager: relations LWP: lightweight processes, threads légers Ch.5

Flots = threads = lightweight processes Processus: programme en exécution Chaque processus a ses variables et fichiers indépendants des autres processus Un thread est une subdivision d`un processus Un fil de contrôle dans un processus Les différents threads d’un processus partagent les variables et les ressources d’un processus lorsqu’un thread modifie une variable (non locale à lui), tous les autres threads voient la modification un fichier ouvert par un thread est accessible aux autres threads (du même processus) Ch.5

Processus à un thread et à plusieurs threads En commun Séparés Ch.5

Exemple Le processus MS-Word peut impliquer plusieurs threads: Interaction avec le clavier Rangement de caractères sur la page Sauvegarde régulière du travail fait Contrôle orthographe Etc. Ces threads partagent tous le même fichier .doc et autres données Ch.5

Threads et processus [Stallings] Ch.5

Processus Possède sa mémoire, ses fichiers, ses ressources, etc. Accès à la mémoire, fichiers, ressources d’autres processus Mais à l’entremise du SE Ch.5

Thread Possède un état d’exécution (prêt, attente…) Possède sa pile et un espace privé pour variables locales A accès à l’espace adressable, fichiers et ressources du processus auquel il appartient En commun avec les autres threads du même proc Ch.5

Pourquoi les threads Reactivité: un processus peut être subdivisé en plusieurs threads, L’un peut exécuter tant que l’autre attend Utilisation de multiprocesseurs: les threads peuvent exécuter en parallèle sur des UCT différentes Ch.5

Un processus possède mémoire, fichiers, autres ressources La commutation entre threads est moins dispendieuse que la commutation entre processus Un processus possède mémoire, fichiers, autres ressources Changer d`un processus à un autre implique sauvegarder et rétablir l’état de tout ça Changer d’un thread à un autre dans le même proc est bien plus simple, implique sauvegarder seulement les registres de l’UCT, les vars locales du thread, Incluant sa pile Ch.5

Étant donné que les threads partagent leur mémoire, La communication aussi est moins dispendieuse entre threads d’un proc qu’entre proc Étant donné que les threads partagent leur mémoire, la communication entre threads dans un même processus est plus efficace que la communication entre processus elle utilise les variables qui sont en commun entre threads Ch.5

La création et terminaison sont moins dispendieuses La création et terminaison de nouveaux threads dans un processus existant sont aussi moins dispendieuses que la création ou terminaison d’un processus Ch.5

Threads de noyau (kernel) et d’utilisateur Où implémenter les threads: Dans les bibliothèques d’usager ou dans le système d’exécution du langage utilisé (Java?) contrôlés directement ou indirectement par l’usager Dans le noyau du SE: contrôlés par le noyau Solutions mixtes Ch.5

Threads d’utilisateur et de noyau (kernel) Threads de noyau: supportés directement par le noyau du SE (Windows, Linux) les ops sur les threads sont des appels au système le noyau est capable de gérer directement les états des threads Il peut affecter différents threads à différentes UCTs Threads d’utilisateur: supportés par des bibliothèques d’usager ou le langage de prog (p.ex Java) les ops sur les threads ne demandent pas des appels du système sont gérées par le système d’exécution du langage de programmation (p.ex. Java) le noyau ne peut pas les gérer directement Ch.5

Solutions mixtes: threads utilisateur et noyau Relation entre threads utilisateur et threads noyau plusieurs à un un à un plusieurs à plusieurs (v. Lightweight Processes) Nous devons prendre en considération plusieurs niveaux: Processus Thread usager Thread noyau Processeur (UCT) Ch.5

Plusieurs threads utilisateur pour un thread noyau: l’usager ou son langage de progr. contrôle les threads usager noyau Le SE ne connaît pas les threads utilisateur v. avantages et désavantages mentionnés avant Ch.5

Un vers un: le SE contrôle les threads usager noyau Les ops sur les threads sont des appels du système Permet à un autre thread d’exécuter lorsqu’un thread exécute un appel de système Ch.5

Plusieurs à plusieurs: solution mixte usager noyau Flexibilité pour l’usager d’utiliser la technique qu’il préfère Si un thread utilisateur attend, son thread noyau peut être affecté à un autre utilisateur Si plus. UCT sont disponibles, plus. threads noyau peuvent exécuter en même temps Complexité: les threads usager et les thread noyau doivent être ordonnancés séparément et ceci peut causer des inefficacités et impasses Ch.5

Concept de Light-Weight Process (LWP) Les LWP sont des UCT virtuelles Représentent des threads de noyau qui peuvent exécuter des threads d’usager Concept implémenté dans plusieurs systèmes d’exploitation Ch.5

Lightweight processes implémentés dans quelques versions de Unix (Tâche = processus) 9 thread niveau usager 7 processus légers 9 threads noyau (2 inactifs) 4 Unités Centrales Plusieurs à plusieurs, usager et noyau Ch.5

Processus légers (lightweight, LWP) Implémentent le concept d’UCT virtuelle, pouvant exécuter des threads niveau usager Il y a des ordonnanceurs pour les LWP comme pour les UCT, et leurs logiques sont semblables à ce que nous avons vu (états prêt, en attente, etc.) Il y a un thread noyau pour chaque LWP Les threads utilisateur sont exécutés sur les LWP disponibles Si un thread noyau attend, ses LWPs et ses threads usagers attendent aussi Seulement les threads usager qui sont associés à un LWP peuvent exécuter, les autres seront prêts pour un LWP Thread usager LWP Thread noyau UCT Ch.5

Revenons aux deux méthodes d’E/S La méthode (a) d’attente sur E/S est conceptuellement la plus simple Nous pouvons travailler avec la méthode (a) si nous avons assez d’UCT, qui peuvent rester en attente dans les E/S Le SE peut créer un nombre arbitraire de LWP Ch.5

Plutôt génial … Par rapport aux LWP, nous utilisons ici la méthode d’E/S (a): Le LWP attend le complètement de l’E/S Mais par rapport à l’UCT réelle, nous utilisons la méthode (b) Dans l’attente l’UCT est allouée à un autre LWP, s’il y en a Ch.5

Exemple simple Exemple simple Un lightweight process LWP1 exécute le processus A A demande une écriture disque Un LWP2 est créé pour cette écriture et reste en attente du résultat Dans l’entretemps A peut continuer avec autres traitements sur LWP1, puis quand A a vraiment besoin du résultat de la lecture disque, il effectue une ‘wait’ pour LWP2 Quand l’écriture disque se termine, LWP2 réveille LWP1 et LWP1 peut continuer Dans l’entretemps, les UCTs disponibles peuvent être allouées à à autres threads ou processus selon la méthode d’ordonnancement des UCT Ch.5

Cas général Utilisation des LWP Quand un thread usager fait un appel au SE, p.ex. E/S, on crée un nouveau LWP pour s’occuper de cette opération le premier LWP peut continuer l’exécution du thread Il y a besoin d’un LWP pour chaque thread qui peut devoir attendre pour un appel de système un programme qui ne fait qu’exécuter sur l’UCT a besoin d’un seul thread s ’il y a 5 demandes d’E/S en même temps, 5 LWP nous permettent de les lancer (virtuellement) en même temps si on est limité à 4 LWP, une des demandes d ’E/S doit attendre qu’un LWP devienne libre ou puisse être créé Ch.5

Exécution des LWP: flexibilité Les threads de noyau qui implémentent les LWP exécutent sur les UCT qui deviennent disponibles Si un thread noyau doit attendre, son LWP doit attendre aussi, mais un processus (tâche) peut en obtenir un autre, ou un nouveau LWP peut être créé Si un LWP doit attendre, l’UCT qui l’exécute peut être affectée à un autre thread Ch.5

Structures de données: Solaris Une tâche=processus Solaris peut être associée à plusieurs LWP Un LWP contient un ensemble de registres, les vars locales etc. PCB du proc Données pour chaque LWP dans le proc principal Ch.5

Dans les sessions exercices, vous verrez comment Java implémente les threads vous cachant tous ces mécanismes Ch.5

Concepts importants du Chap. 5 threads et processus: différence threads de noyau et d’usager: relations LWP: lightweight processes, processus légers Implémentation utilisant UCT physiques Ch.5

Questions de révision 1 Quelles sont les informations qu’il faut sauvegarder ou non dans le cas de changement de thread par rapport au cas de changement de processus Quelles sont les informations que différents threads partagent Pourquoi il coûte moins de changer d’un thread à l’autre d’un processus que de changer de processus Pourquoi il coûte moins de communiquer entre threads d’un seul processus que de communiquer entre différents processus Ch.5

Questions de révision 2 Si un thread d’usager doit attendre, est-ce-que ceci bloque nécessairement une UCT? Expliquer. Si une UCT devient bloquée, est-ce-que ceci bloque nécessairement un thread d’usager? Expliquer. Est-ce-que l’état d’un thread utilisateur doit être le même que l’état du thread noyau correspondant? Vrai ou faux: il y a un seul ordonnanceur pour threads et UCT Ch.5

Quoi étudier dans le manuel En classe, nous avons vu seulement 5.1- 5.2 et 5.3.6 5.3.1 jusqu’à 5.3.5 sont utiles pour mieux comprendre mais pas matière d’examen 5.4 et 5.5 sont intéressants mais ils ne sont pas matière d’examen Pendant les sessions exercices vous verrez 5.6 et suivants Ch.5