Changes between Version 25 and Version 26 of DevloperManuel


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

--

Legend:

Unmodified
Added
Removed
Modified

  • DevloperManuel

    v25 v26  
    1 = Manuel de développement =  [[PageOutline]]
     1= Manuel de développement = 
     2[[PageOutline]]
    23
    34== 1. Architecture du MUTEKP ==
    45
    5 La figure suivante illustre la modélisation du système : [[BR]] [[Image(modalisation_mutekp.png, nolink)]][[BR]]
     6La figure suivante illustre la modélisation du système :
     7[[Image(modalisation_mutekp.png, nolink)]]
     8
    69Les 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.
     10 *  `pthread `: contient l'interface système des Threads POSIX.
     11 *  `libc    `: contient l’interface des services système tel que malloc, printf, read, memcpy, ... etc.
     12 *  `mwmr    `: contient l’interface système des FIFO MWMR.
     13 *  `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.
     14 *  `cpu     `: contient le code système en assembleur qui dépend de type des processeurs de la plate-forme.
     15 *  `arch    `: contient le code C qui dépend de la plate-forme tel que les configurations du système vis-à-vis des
     16    composants de la plate-forme, les ISR d’interruption des différant types de cibles... etc.
    1317
    1418En 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.
    … …  
    1721
    1822=== 2.1 Le concept d’un Thread dans le système ===
    19 [[Image(Application.PNG, nolink)]][[BR]][[BR]]
     23[[Image(Application.PNG, nolink)]]
     24Un Thread est un fil d’exécution d’un programme.
    2025
    21 Un Thread est un fil d’exécution d’un programme. [[BR]]
    2226Tous les Threads de l’application partagent le même espace d’adressage, où chaque Thread possède : 
    23 
    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
     27 * Son propre contexte d’exécution (le PC, un pointeur de pile et d’autres registres de travail du processeur).
     28 * Deux piles.   
     29 * Plie utilisateur   
     30 * Pile système
    2831
    2932Quelques avantages :
    30 
    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.
     33 * Création et gestion plus rapide (vs processus).
     34 * Partage des ressources par défaut.
     35 * Communication entre les Threads plus simple via la mémoire (les variables globales).
     36 * Déploiement plus efficace de l’application sur des architectures multiprocesseurs.
    3537
    3638=== 2.2 États d’un Thread ===
    37 [[Image(Thread_states.PNG, nolink)]][[BR]][[BR]]
     39[[Image(Thread_states.PNG, nolink)]]
    3840
    39 La durée de vie d’un Thread peut être divisée en un ensemble d’états.[[BR]]
     41La durée de vie d’un Thread peut être divisée en un ensemble d’états.
    4042Les 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.
     43 * Run : quand le Thread s’exécute sur le processeur en faisant son calcul.
     44 * Kernel : quand le Thread « tombe » dans le noyau suite à un appel aux services noyau ou une interruption
     45   matérielle.
     46 * Wait : lors que le Thread demande une ressource qui n’est pas disponible.
     47 * Ready : quand le Thread est en attente de gagner le processeur pour poursuivre son exécution.
     48 * Zombie : quand le Thread se termine en attendant qu’un autre thread prenne acte de sa terminaison.
     49 * Create : état spécial dans lequel le Thread vient d’être créé. Il n’a pas encore été chargé sur un processeur
     50   et attend de le gainer pour la première fois.
     51 * Dead : état spécial dans lequel le Thread est déclaré définitivement mort. Toute tentative de joindre un
     52   Thread dans cet état échouera.
    4853
    4954=== 2.3 Ordonnancement des Threads ===
    … …  
    5560
    5661Supposant 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).
     62 * Le système partitionne l’ensemble des Threads de l’application en N sous-ensembles.
     63 * Le système dispose de N structures d’ordonnancement pour ordonnancer ces N sous-ensembles.
     64 * En régime permanent (lors que chaque processeur est en train d’exécuter un Thread), il existe N Threads 
     65   s’exécutant en parallèle, tandis que les autres Threads de chaque sous-ensemble s’exécutent en pseudo   
     66   parallèle grâce au temps partagé (changement de contexte à chaque fin de quantum suite à une interruption
     67   horloge).
    6068
    6169Ainsi le noyau Mutek''P'' dispose d’un mécanisme d’ordonnancement distribué à tâches affectées.
    62 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]]
    63 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 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.
     70Dans le cas où l’Ordonnanceur d’un processeur ne trouve aucun Thread à l’état Ready, Il charge un Thread particulier nommé Thread Idle. 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 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.
    6471
    6572L’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.
     73 * Pour ne pas bloquer le processeur vis-à-vis des interruptions et de pouvoir ainsi exécuter leurs ISR.
     74 * Peut être programmé pour exécuter un code spécial de débogage ou d’observation de l’état du système.
    6875
    6976=== 2.4 Organisation et gestion de la mémoire ===
    … …  
    7279
    7380L’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
     81 * Les registres de contrôle des périphériques 
     82 * Les segments de RAM (ROM) réservés au système
     83 * Les segments de RAM (ROM) de l'utilisateur
    7784
    7885Les 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).
    79 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ée dans le cache du processeur. 
     86Les 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. 
    8087
    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.
     88 * En cas de hit, le contrôleur du cache fournit la donnée au processeur évitant ainsi de réaliser un accès à la
     89   mémoire.
     90 * 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
     91   au processeur.
    8392
    8493Si 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.
    8594
    8695Consé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.
     96 * Les variables globales de l'application et du système doivent être mappées dans un segment de type non caché.
     97 * La structure de la pile d'un Threads est mappée dans un segment de type caché (puisqu’aucun Thread ne modifie
     98   pas la pile d'un autre Thread !).
     99 * L'échange de données entre Threads passe par de la mémoire non caché ou une invalidation partielle du cache.
    90100
    91 === 2.4.2 La gestion de la mémoire ====
     101==== 2.4.2 La gestion de la mémoire ====
    92102
    93103Quatre 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
     104 * mémoire cachée et non cachée système
     105 * mémoire cachée et non cachée utilisateur
    96106
    97107Le 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.