Manuel de développement :

I. Architecture du MUTEKP

La figure suivante illustre la modalisation du système :

Les bibliothèques constituant le système sont :

• pthread : contient l’implémentation d’un sous-ensemble des Thread POSIX.
• libc : contient l’implémentation des services système tel que malloc, printf, read, memcpy ..etc.
• mwmr : contient l’implémentation du protocole MWMR.
• 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.
• cpu : contient le code système en assembleur qui dépend de type des processeurs de la plate-forme.
• 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.

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 MUTEKP sur la nouvelle plate-forme.

II. Introduction au noyau MUTEKP

II.1 Le concept d’un Thread dans le système

Un Thread est un fil d’exécution d’un programme.
Tous les Threads de l’application partagent le même espace d’adressage, où chaque Thread possède :

• Son propre contexte d’exécution (le PC, un pointeur de pile et d’autres registres de travail du processeur).
• Deux piles.
  • Plie utilisateur
  • Pile système

Quelques avantages :

• Création et gestion plus rapide (vs processus).
• Partage des ressources par défaut.
• Communication entre les Threads plus simple via la mémoire (les variables globales).
• Déploiement plus efficace de l’application sur des architectures multi-processeurs.

II.2 États d’un Thread

La duré de vie d’un Thread peut être divisée en un ensemble d’états.
Les différents états d’un Thread sont :

• Run : quand le Thread s’exécute sur le processeur en faisant son calcul.
• Kernel : quand le Thread « tombe » dans le noyau suite à un appel aux services noyau ou une interruption matérielle.
• Wait : lors que le Thread demande une ressource qui n’est pas disponible.
• Ready : quand le Thread est en attente de gagner le processeur pour poursuivre son exécution.
• Zombie : quand le Thread se termine en attendant que un autre thread pren acte de sa terminaison.
• 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.
• 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.

II.3 Ordonnancement des Threads

Le système partitionne l’ensemble des threads de l’application en sous-ensembles dans le but de les ordonnancer.
Le nombre de ces sous-ensembles est en bijection avec le nombre des processeurs disponibles dans la plate-forme matérielle.
Il existe une structure d’ordonnancement, pour chaque sous-ensemble, responsable de l’ordonnancement de ses Threads selon sa propre politique d’ordonnancement.
Une fois un Thread est crée, il est affecté à un seul processeur tout au long de sa vie, le noyau MutekP n’implémente pas la migration des tâches, ou la répartition dynamique de la charge du système.
Supposant que le nombre des processeurs dans la plate-forme est égal à N alors :

• Le système partitionne l’ensemble des Threads de l’application en N sous-ensembles.
• Le système dispose de N structures d’ordonnancement pour ordonnancer ces N sous-ensembles.
• En régime permanant (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écute en pseudo parallèle grâce au temps partagé (changement de contexte à chaque fin de quantum suite à une interruption horloge).

Ainsi le noyau MutekP dispose d’un mécanisme d’ordonnancement distribué à taches affectées.
Dans 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 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.
L’utilité de ce Thread Idle est double :

• Pour ne pas bloquer le processeur vis-à-vis des interruptions et de pouvoir ainsi exécuter leurs ISR.
• Peut être programmé pour exécuter un code spécial de débugage ou d’observation de l’état du système.

II.4 Organisation et gestion de la mémoire

II.4.1 L’organisation mémoire

II.4.2 La gestion mémoire

II.6 Le buffer système

III. Détaille du noyau et les structures de données système

III.1 Gestion des threads

III.1.1 La structure de donnée du thread

III.1.2 La structure de donnée Ordonnanceur et la table d’ordonnancement

III.2 Gestion de la mémoire

III.2.1 La structure gestionnaire mémoire

III.3 Gestion des périphériques

III.3.1 La structure gestionnaire des verrous

III.3.2 Représentation des cibles (TTY, Timer et ICU)

III.4 Gestion des interruptions