Changes between Version 23 and Version 24 of DevloperManuel
- Timestamp:
- Jan 19, 2008, 4:53:48 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevloperManuel
v23 v24 2 2 [[PageOutline]] 3 3 == I. Architecture du MUTEKP == 4 La figure suivante illustre la mod alisation du système : [[BR]]4 La figure suivante illustre la modélisation du système : [[BR]] 5 5 [[Image(modalisation_mutekp.png, nolink)]][[BR]] 6 6 Les bibliothèques constituant le système sont : 7 * pthread : contient l ’implémentation d’un sous-ensemble des ThreadPOSIX.8 * libc : contient l’i mplémentationdes services système tel que malloc, printf, read, memcpy ..etc.9 * mwmr : contient l’i mplémentation du protocoleMWMR.7 * pthread : contient l'interface système des Threads POSIX. 8 * libc : contient l’interface des services système tel que malloc, printf, read, memcpy ..etc. 9 * mwmr : contient l’interface système des FIFO MWMR. 10 10 * sys : contient le code système qui ne dépend pas de l'architecture de la plate-forme ou de type des processeurs utilisés. 11 11 * cpu : contient le code système en assembleur qui dépend de type des processeurs de la plate-forme. 12 * arch : contient le code C qui dépend de la plate-forme tel que des configurations système vis-à-vis des composants de la plate-forme, les ISR d’interruption des différant types de cibles ..etc.12 * arch : contient le code C qui dépend de la plate-forme tel que les configurations système vis-à-vis des composants de la plate-forme, les ISR d’interruption des différant types de cibles ..etc. 13 13 14 En cas de modification au niveau de la configuration matériel , il suffit d’adapter le code système des deux bibliothèques cpu et arch pour pouvoir déployer MUTEKPsur la nouvelle plate-forme.14 En cas de modification au niveau de la configuration matérielle, il suffit d’adapter le code système des deux bibliothèques cpu et arch pour pouvoir déployer Mutek''P'' sur la nouvelle plate-forme. 15 15 16 16 == II. Introduction au noyau MUTEKP == … … 39 39 * Wait : lors que le Thread demande une ressource qui n’est pas disponible. 40 40 * Ready : quand le Thread est en attente de gagner le processeur pour poursuivre son exécution. 41 * Zombie : quand le Thread se termine en attendant que un autre thread pren acte de sa terminaison.41 * Zombie : quand le Thread se termine en attendant que un autre thread prenne acte de sa terminaison. 42 42 * Create : état spécial dans le quel le Thread vient d’être crée. Il n’a pas encore été chargé sur un processeur et attend de le gainer pour la première fois. 43 43 * Dead : état spécial dans le quel le Thread est déclaré définitivement mort. Toute tentative de joindre un Thread dans cet état échouera. … … 58 58 * Le système partitionne l’ensemble des Threads de l’application en N sous-ensembles. 59 59 * Le système dispose de N structures d’ordonnancement pour ordonnancer ces N sous-ensembles. 60 * En régime perman ant (lors que chaque processeur est entrain d’exécuter un Thread), il existe N Threads s’exécute en parallèle, tandis que les autres Threads de chaque sous-ensemble s’exécuteen pseudo parallèle grâce au temps partagé (changement de contexte à chaque fin de quantum suite à une interruption horloge).60 * En régime permanent (lors que chaque processeur est entrain d’exécuter un Thread), il existe N Threads s’exécutent en parallèle, tandis que les autres Threads de chaque sous-ensemble s’exécutent en pseudo parallèle grâce au temps partagé (changement de contexte à chaque fin de quantum suite à une interruption horloge). 61 61 62 62 63 Ainsi le noyau Mutek''P'' dispose d’ un mécanisme d’ordonnancement distribué à taches affectées.63 Ainsi le noyau Mutek''P'' dispose d’__un mécanisme d’ordonnancement distribué à tâches affectées. 64 64 65 65 … … 72 72 * Peut être programmé pour exécuter un code spécial de débugage ou d’observation de l’état du système. 73 73 === II.4 Organisation et gestion de la mémoire === 74 ==== II.4.1 L' Organisation de la mémoire ====74 ==== II.4.1 L'organisation de la mémoire ==== 75 75 76 76 77 L’espace d’adressage est découpé en segments d'adresses contig uës :77 L’espace d’adressage est découpé en segments d'adresses contigües : 78 78 * Les registres de contrôle des périphériques 79 79 * Les segments de RAM (ROM) réservé au système … … 93 93 * Les variables globales de l'application et du système doivent êtres mappées dans un segment de type non caché. 94 94 * La structure de la pile d'un Threads est mappée dans un segment de type caché (puisque aucun Thread ne modifie pas la pile d'un autre Thread !). 95 * L'échange de données entre threads passe par de la mémoire non caché ou une invalidation partiel du cache.95 * L'échange de données entre Threads passe par de la mémoire non caché ou une invalidation partiel du cache. 96 96 97 97 … … 121 121 122 122 123 Ces buffers système permettent au noyau de pouvoir stocker le flux de caractères qui arrive depuis un terminal TTY en attendant qu’un thread puisse les consommer (c.f: read())123 Ces buffers système permettent au noyau de pouvoir stocker le flux de caractères qui arrive depuis un terminal TTY en attendant qu’un Thread puisse les consommer (c.f: read()) 124 124 == III. Détaille du noyau et les structures de données système == 125 === III.1 Gestion des threads ===126 ==== III.1.1 La structure de donnée du thread ====125 === III.1 Gestion des Threads === 126 ==== III.1.1 La structure de donnée du Thread ==== 127 127 ==== III.1.2 La structure de donnée Ordonnanceur et la table d’ordonnancement ==== 128 128 === III.2 Gestion de la mémoire ===
