Changes between Version 24 and Version 25 of DevloperManuel


Ignore:
Timestamp:
Jan 20, 2008, 6:19:50 PM (16 years ago)
Author:
franck
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DevloperManuel

    v24 v25  
    1 = Manuel de développement : =
    2 [[PageOutline]]
    3 == I. Architecture du MUTEKP ==
    4 La figure suivante illustre la modélisation du système : [[BR]]
    5 [[Image(modalisation_mutekp.png, nolink)]][[BR]]
    6 Les bibliothèques constituant le système sont :
    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  *  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  *  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 les configurations système vis-à-vis des composants de la plate-forme, les ISR d’interruption des différant types de cibles ..etc.
     1= Manuel de développement =  [[PageOutline]]
     2
     3== 1. Architecture du MUTEKP ==
     4
     5La figure suivante illustre la modélisation du système : [[BR]] [[Image(modalisation_mutekp.png, nolink)]][[BR]]
     6Les bibliothèques constituant le système sont : 
     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*  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*  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 les configurations du système vis-à-vis des composants de la plate-forme, les ISR d’interruption des différant types de cibles... etc.
    1313
    1414En 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.
    1515
    16 == II. Introduction au noyau MUTEKP ==
    17 === II.1 Le concept d’un Thread dans le système ===
     16== 2. Introduction au noyau MUTEKP ==
     17
     18=== 2.1 Le concept d’un Thread dans le système ===
    1819[[Image(Application.PNG, nolink)]][[BR]][[BR]]
     20
    1921Un Thread est un fil d’exécution d’un programme. [[BR]]
    20 Tous les Threads de l’application partagent le même espace d’adressage, où chaque Thread possède :
    21  * Son propre contexte d’exécution (le PC, un pointeur de pile et d’autres registres de travail du processeur).
    22  * Deux piles.
    23     * Plie utilisateur
    24     * Pile système
     22Tous les Threads de l’application partagent le même espace d’adressage, où chaque Thread possède : 
    2523
    26 Quelques avantages :
     24* Son propre contexte d’exécution (le PC, un pointeur de pile et d’autres registres de travail du processeur).
     25* Deux piles.   
     26* Plie utilisateur   
     27* Pile système
    2728
    28  * Création et gestion plus rapide (vs processus).
    29  * Partage des ressources par défaut.
    30  * Communication entre les Threads plus simple via la mémoire (les variables globales).
    31  * Déploiement plus efficace de l’application sur des architectures multi-processeurs.
     29Quelques avantages :
    3230
    33 === II.2 États d’un Thread ===
     31* Création et gestion plus rapide (vs processus).
     32* Partage des ressources par défaut.
     33* Communication entre les Threads plus simple via la mémoire (les variables globales).
     34* Déploiement plus efficace de l’application sur des architectures multiprocesseurs.
     35
     36=== 2.2 États d’un Thread ===
    3437[[Image(Thread_states.PNG, nolink)]][[BR]][[BR]]
    35 La duré de vie d’un Thread peut être divisée en un ensemble d’états.[[BR]]
    36 Les différents états d’un Thread sont :
    37  * Run : quand le Thread s’exécute sur le processeur en faisant son calcul.
    38  * Kernel : quand le Thread « tombe » dans le noyau suite à un appel aux services noyau ou une interruption matérielle.
    39  * Wait : lors que le Thread demande une ressource qui n’est pas disponible.
    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 prenne acte de sa terminaison.
    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  * 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.
    44 === II.3 Ordonnancement des Threads ===
    4538
     39La durée de vie d’un Thread peut être divisée en un ensemble d’états.[[BR]]
     40Les différents états d’un Thread sont :
     41* Run : quand le Thread s’exécute sur le processeur en faisant son calcul.
     42* Kernel : quand le Thread « tombe » dans le noyau suite à un appel aux services noyau ou une interruption matérielle.
     43* Wait : lors que le Thread demande une ressource qui n’est pas disponible.
     44* Ready : quand le Thread est en attente de gagner le processeur pour poursuivre son exécution.
     45* Zombie : quand le Thread se termine en attendant qu’un autre thread prenne acte de sa terminaison.
     46* Create : état spécial dans lequel le Thread vient d’être créé. Il n’a pas encore été chargé sur un processeur et attend de le gainer pour la première fois.
     47* Dead : état spécial dans lequel le Thread est déclaré définitivement mort. Toute tentative de joindre un Thread dans cet état échouera.
    4648
    47 Le système partitionne l’ensemble des threads de l’application en sous-ensembles dans le but de les ordonnancer.
     49=== 2.3 Ordonnancement des Threads ===
    4850
    49 
     51Le système partitionne l’ensemble des Threads de l’application en sous-ensembles dans le but de les ordonnancer.
    5052Le nombre de ces sous-ensembles est en bijection avec le nombre des processeurs disponibles dans la plate-forme matérielle.
    5153Il existe une structure d’ordonnancement, pour chaque sous-ensemble, responsable de l’ordonnancement de ses Threads selon sa propre politique d’ordonnancement.
     54Une fois qu’un Thread est créé, il est affecté à un seul processeur tout au long de sa vie, le noyau Mutek''P'' n’implémente pas la migration de tâches, ou la répartition dynamique de la charge du système.
    5255
     56Supposant que le nombre des processeurs dans la plate-forme est égal à N alors :
     57* Le système partitionne l’ensemble des Threads de l’application en N sous-ensembles.
     58* Le système dispose de N structures d’ordonnancement pour ordonnancer ces N sous-ensembles.
     59* En régime permanent (lors que chaque processeur est en train d’exécuter un Thread), il existe N Threads s’exécutant 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).
    5360
    54 Une fois un Thread est crée, il est affecté à un seul processeur tout au long de sa vie, le noyau Mutek''P'' n’implémente pas la migration des tâches, ou la répartition dynamique de la charge du système.
     61Ainsi le noyau Mutek''P'' dispose d’un mécanisme d’ordonnancement distribué à tâches affectées.
     62Dans le cas où l’Ordonnanceur d’un processeur ne trouve aucun Thread à l’état Ready, Il charge un Thread particulier nommé Thread Idle.[[BR]]
     63Cette situation peut se produire notamment au démarrage du système et avant la création des Threads de l’application, aucun Thread n’est disponible pour être chargé sur un processeur (exception du Thread main). Ou encore lors que tous les Threads d’un processeur sont en attente sur des ressources non disponibles.
    5564
     65L’utilité de ce Thread Idle est double :
     66* Pour ne pas bloquer le processeur vis-à-vis des interruptions et de pouvoir ainsi exécuter leurs ISR.
     67* Peut être programmé pour exécuter un code spécial de débogage ou d’observation de l’état du système.
    5668
    57 Supposant que le nombre des processeurs dans la plate-forme est égal à N alors :
    58  * Le système partitionne l’ensemble des Threads de l’application en N sous-ensembles.
    59  * Le système dispose de N structures d’ordonnancement pour ordonnancer ces N sous-ensembles.
    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).
     69=== 2.4 Organisation et gestion de la mémoire ===
    6170
     71==== 2.4.1 L'organisation de la mémoire ====
    6272
    63 Ainsi le noyau Mutek''P'' dispose d’__un mécanisme d’ordonnancement distribué à tâches affectées.
     73L’espace d’adressage est découpé en segments d'adresses contigües :
     74* Les registres de contrôle des périphériques 
     75* Les segments de RAM (ROM) réservés au système
     76* Les segments de RAM (ROM) de l'utilisateur
    6477
     78Les informations sur les segments de mémoire dépendent de la plate-forme matérielle. Le système les connait par l'intermédiaire du fichier segmentation.h (dans le répertoire arch_soclib).
     79Les propriétés (caché / non caché), (système / utilisateur) sont codées dans les adresses. La lecture d'une donnée dans un segment caché est d’abord recherchée dans le cache du processeur. 
    6580
    66 Dans le cas où l’Ordonnanceur d’un processeur ne trouve aucun Thread à l’état Ready, Il charge un Thread particulier nommé Thread Idle.[[BR]]
    67 Cette situation peut se produire notamment au démarrage du système et avant la création des Threads de l’application, aucun Thread n’est disponible pour être charger sur un processeur (exception du Thread main). Ou encore lors que touts les Threads d’un processeur sont en attente sur des ressources non disponibles.
     81* En cas de hit, le contrôleur du cache fournit la donnée au processeur évitant ainsi de réaliser un accès à la mémoire.
     82* En cas de miss, le contrôleur du cache réalise la mise à jour d'une ligne de cache avant de  fournir la donnée au processeur.
    6883
    69 
    70 L’utilité de ce Thread Idle est double :
    71  * Pour ne pas bloquer le processeur vis-à-vis des interruptions et de pouvoir ainsi exécuter leurs ISR.
    72  * Peut être programmé pour exécuter un code spécial de débugage ou d’observation de l’état du système.
    73 === II.4 Organisation et gestion de la mémoire ===
    74 ==== II.4.1 L'organisation de la mémoire ====
    75 
    76 
    77 L’espace d’adressage est découpé en segments d'adresses contigües :
    78  * Les registres de contrôle des périphériques
    79  * Les segments de RAM (ROM) réservé au système
    80  * Les segments de RAM (ROM) de l'utilisateur
    81 
    82 
    83 Les informations sur les segments mémoire dépendent de la plate-forme matérielles. Le système les connait par l'intermédiaire du fichier segmentation.h (dans le répertoire arch_soclib).
    84 
    85 
    86 Les propriétés (caché / non caché), (système / utilisateur) sont codées dans les adresses, La lecture d'une donnée dans un segment caché est d’abord recherché dans le cache du processeur.
    87  * En cas de hit, le contrôleur du cache fournit la donnée au processeur évitant ainsi de réaliser un accès à la mémoire.
    88  * En cas de miss, le contrôleur du cache réalise la mise à jour d'une ligne de cache avant de  fournir la donnée au processeur.
    8984Si un cache contient la copie du contenu d'une adresse mémoire et que cette adresse est modifiée par un autre processeur, alors le cache n'est pas à jour.
    9085
     86Conséquence de ce comportement
     87* Les variables globales de l'application et du système doivent être mappées dans un segment de type non caché.
     88* La structure de la pile d'un Threads est mappée dans un segment de type caché (puisqu’aucun Thread ne modifie pas la pile d'un autre Thread !).
     89* L'échange de données entre Threads passe par de la mémoire non caché ou une invalidation partielle du cache.
    9190
    92 Conséquence de ce comportement
    93  * Les variables globales de l'application et du système doivent êtres mappées dans un segment de type non caché.
    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.
     91=== 2.4.2 La gestion de la mémoire ====
    9692
     93Quatre segments de mémoire data : 
     94* mémoire cachée et non cachée système
     95* mémoire cachée et non cachée utilisateur
    9796
    98 ==== II.4.2 La gestion de la mémoire ====
     97Le noyau gère ces zones mémoire d’une manière minimaliste, qui consiste à garder quatre pointeurs, dans une structure de donnée dédiée, définissant l’occupation de ces zones.
     98À chaque allocation, l’espace disponible est vérifié, s’il n'y en a plus, le système retourne un pointeur nul, sinon il mis à jours le pointeur de la zone allouée.
     99Le système ne propose pas de libérer une zone mémoire dynamiquement allouée.
    99100
    100 
    101 Quatre segments de mémoire data :
    102  * mémoire cachées et non cachée système
    103  * mémoire cachées et non cachée utilisateur
    104 Le noyau gère ces zones mémoire d’une manière minimaliste, qui consiste à garder quatres pointeurs, dans une structure de donnée dédié, définissant l’occupation de ces zones.
    105 
    106 
    107 A chaque allocation, l’espace disponible est vérifié, s’il n'y en a plus, le système retourne un pointeur nul, sinon il mis à jours le pointeur de la zone allouée.
    108 
    109 
    110 Le système ne propose pas de libérer une zone mémoire dynamiquement allouée.
    111 === II.5 Le buffer système ===
    112 
     101=== 2.5 Le buffer système ===
    113102
    114103Le noyau dispose d’un tableau de tampons système.
     104Chaque entrée de ce tableau est une structure de type FIFO MWMR réalisent un tampon.
     105L’index de chaque tampon est utilisé en tant que descripteur du buffer
     106Ces buffers système permettent au noyau de pouvoir stocker le flux de caractères qui arrivent depuis un terminal TTY en attendant qu’un Thread puisse les consommer (c.f: read())
    115107
     108== 3. Détails du noyau et des structures de données système ==
    116109
    117 Chaque entrée de ce tableau est une structure de type FIFO MWMR réalisent un tampon.
     110=== 3.1 Gestion des Threads ===
    118111
     112==== 3.1.1 La structure de donnée du Thread ====
    119113
    120 L’index de chaque tampon est utilisé en tant que descripteur du buffer
     114==== 3.1.2 La structure de donnée Ordonnanceur et la table d’ordonnancement ====
    121115
     116=== 3.2 Gestion de la mémoire ===
    122117
    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 == 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 ====
    127 ==== III.1.2 La structure de donnée Ordonnanceur et la table d’ordonnancement ====
    128 === III.2 Gestion de la mémoire ===
    129 ==== III.2.1 La structure gestionnaire mémoire ====
    130 === III.3 Gestion des périphériques ===
    131 ==== III.3.1 La structure gestionnaire des verrous ====
    132 ==== III.3.2 Représentation des cibles (TTY, Timer et ICU) ====
    133 === III.4 Gestion des interruptions ===
     118==== 3.2.1 La structure gestionnaire mémoire ====
     119
     120=== 3.3 Gestion des périphériques ===
     121
     122==== 3.3.1 La structure gestionnaire des verrous ====
     123
     124==== 3.3.2 Représentation des cibles (TTY, Timer et ICU) ====
     125
     126=== 3.4 Gestion des interruptions ===