Introduction

Multi-Tâches Création de CPU virtuelles Economique en matériel Nécessite une couche de logicielMulti-Cœur L’UC fait « plusieurs choses » Justifié par la loi de MOORE Le logiciel doit s’adapter…

Le Multi-Tâches

Tâche A Tâche B En attente du processeur Commutation de contexte

CSW CSW CSW Tâche A Tâche B CPU TCB_ A TCB_ B

Tâche A Tâche B YIELD YIELD YIELD Coopération

La commutation de contexte n’intervient que suite à un appel explicite dans la tâche en cours La tâche prend le risque de se faire « arrêter » Le code de commutation de tâche s’exécute dans le contexte de la tâche qui fait l’appel Le code de changement de contexte peut être « linké » Tout est parfaitement séquentiel Le séquencement est entièrement écrit par les développeurs des applications

Tâche A Tâche B OrdonnanceurSleep(dt) WakeUp !! Préemption TICK

La commutation de contexte intervient sur un critère extérieur au flux d’exécution La tâche préemptée « n’a rien demandé… » Le code de commutation de tâche s’exécute dans un contexte « hors tâches » Il est nécessaire de faire intervenir une interruption Le code de commutation est critique Notion de TICK système (grain temporel) Il est possible d’effectuer les changements de contexte sans faire intervenir les développeurs

Thread1 Thread2 Préemption Quantum de temps Partage du système entre plusieurs utilisations Mécanisme de « Temps Partagé » avec Quantum Le passage d’une tâche à l’autre est également appelé « Round Robin »

Le changement de contexte doit être précédé d’un travail de planification qui permet de décider quelle tâche doit tourner  Notion de SCHEDULER (Ordonnanceur) Les choix d’implémentation au niveau de la planification sont fortement influencées par l’usage qui sera fait de l’OS: Confort d’utilisation  Planification sophistiquée et très intrusive l’objectif est un équilibrage global en réduisant les risques de blocage. Prédictibilité  Respect strict des éléments fournis par le développeur, en conséquence il doit gérer toute les situations.

Chaque tâche passe par des périodes d’urgence et des périodes de repos (notion de proximité d’une échéance) L’idéal consisterait à planifier de manière dynamique « par échéances » toutefois il faut disposer des temps d ’exécution Cette approche est rarement possible, on passe par une méthode plus brutale On associe à chaque tâche un numéro d’ordre qui permet de déterminer laquelle s’exécute en priorité

Multitâche coopératif ou préemptif FIFO  FAMINE … une tâche ne tourne jamais Multitâche préemptif  ATOMICITE … une donnée est corrompue

Tâche A Compteur++ Tâche B Compteur++ Préemption LOADINCSTO Compteur

Les objets de synchronisation codifient l’interaction entre les tâches Ils permettent de présenter à une tâche un accès exclusif à des données ou ressources partagées L’OS ayant une vue globale de l’ensemble des tâches, il est en mesure de mettre en oeuvre des mécanismes optimisés inaccessibles à une tâche isolée MUTEX - SEMAPHORE - EVENEMENT

Multitâche coopératif ou préemptif  DEADLOCK … attente réciproque Tâche 1 Tâche2

Besoin = Entrées & Sorties à des instants strictement connus (intervalle d’erreur prédéfini) Etat des lieux des CPU Automate Séquentiel & Programmable Pas de gestion interne du temps Temps d’accès à la mémoire & aux périphériques Complexité croissante des besoins !! Quelques mythes Un système temps réel est rapide Le matériel répond à tous les besoins

Au niveau matériel Utilisation des Interruptions Intégration d’un circuit horloge Garantie des temps d’accès à la mémoire Contrôleurs de périphériques et de bus Au niveau logiciel Maîtrise des chemins d’exécution Connaissance des situations de « pire cas » temporel Dans les tâches applicatives Dans le système (Runtimes – Noyau - Pilotes)

Ce qui est de la responsabilité de l’OS Temps de réponse sur interruption Précision du TICK (Timers & Watchdogs) Stabilité des mécanismes internes (KCall, TLB) Stabilité des fonctions exposées (CSW, Synchronisation) Stabilité de la planification des tâches Ce qui n’est pas de la responsabilité de l’OS Contention des interruptions Contention d’accès aux BUS Comportement interne des pilotes de périphériques Ainsi que TOUT le logiciel applicatif !! Ce qui est de la responsabilité de l’OS Temps de réponse sur interruption Précision du TICK (Timers & Watchdogs) Stabilité des mécanismes internes (KCall, TLB) Stabilité des fonctions exposées (CSW, Synchronisation) Stabilité de la planification des tâches Ce qui n’est pas de la responsabilité de l’OS Contention des interruptions Contention d’accès aux BUS Comportement interne des pilotes de périphériques Ainsi que TOUT le logiciel applicatif !!

Oups!Oups!

Pour pallier au problème de consommation, on introduit l’exécution simultanée de programmes Augmenter le Parallélisme d’exécution SMT (Hyper-threading): 2002 (Pentium 4) CMP (Chip Multi Processing): 2005/2006 (Athlon X2, Pentium D, Core Duo) Une des voies d’avenir des processeurs est de faire monter le nombre de cœurs du processeur