Ressource

Ces concepts de liaison et de domaine peuvent s’appliquer dans des systèmes de toutes formes ; réparti, monolithique, micronoyau, exonoyau, embarqué et dédié à une application. Néanmoins, tous les composants d’un système n’ont pas le même rôle. Par exemple, il y a des ressources et des ges- tionnaires de ressources, comme les fils d’exécution et l’ordonnanceur. Il est donc intéressant de faire ressortir ces notions.

L’objectif du modèle de ressource est de fournir une modélisation cohérente et complète de toutes les ressources du système quel que soit le niveau d’abstraction. Par exemple, une approche cohérente doit convenir pour la gestion du processeur, de la mémoire physique ou des ressources réseaux. De façon similaire, le modèle doit inclure les ressources de plus haut niveau comme la mémoire virtuelle, les processus ou les connexions réseaux. Le modèle proposé ici est directement issu des propositions ReTINA [Blair et al. 1999, ReTINA 1999].

3.2. Concepts mis en œuvre 63 Dans ce modèle, le rôle d’un gestionnaire est de permettre le partage d’une ressource ou d’un ensemble de ressources entre plusieurs utilisateurs. Un gestionnaire fournit donc aux utilisateurs une vue abstraite de la ressource qu’il gère. Il contrôle aussi la manière dont les ressources sont utilisées. La figure 3.16 montre comment une ressource de haut niveau est construite à partir d’une ressource de bas niveau par un gestionnaire.

...

gestionnaire

FIGURE3.16 – Modélisation d’un gestionnaire de ressources

Le modèle de ressource n’est en fait qu’un patron de conception destiné à faciliter la compré- hension du code et à simplifier le développement de composants systèmes. Les interfaces décrites dans ce modèle fournissent un ensemble d’interface. Les méthodes sont données à titre indicatif pour expliquer la fonctionnalité attendue. Mais les méthodes réellement utilisées peuvent nécessiter plus ou moins d’arguments et la sémantique indiquée peut varier d’une implantation à une autre.

Ressources abstraites

Dans ce modèle, toutes les ressources de hauts niveaux ou de bas niveaux sont des composants et sont du typeAbstractResource, voir figure 3.17. La méthodereleasepermet de libérer la ressource quand elle n’est plus utilisée. La ressource peut donc être réutilisée par ailleurs. La seule contrainte est de ne plus utiliser la référence sur la ressource après l’appel de cette méthode.

interface AbstractResource { void release(); }

FIGURE3.17 – InterfaceAbstractResource

Gestionnaires

Différentes catégories de gestionnaires peuvent être conçues. Par exemple, un gestionnaire peut multiplexer des ressources de hauts niveaux sur un ensemble de ressources de bas niveaux, comme avec un ordonnanceur. Soit, il peut les coupler directement sur des ressources de bas niveaux, comme

avec un allocateur de mémoire. De façon similaire, un gestionnaire peut composer des ressources de bas niveaux pour créer une ressource plus abstraite de haut niveau, comme avec un processus. La forme générale d’un gestionnaire est donnée par l’interface ResourceManager donnée à la figure 3.18. Cette interface permet uniquement de qualifier un composant, elle est purement indicative et aucune méthode n’est requise.

interface ResourceManager { }

FIGURE3.18 – InterfaceResourceManager

Quand un programme nécessite l’accès à une ressource, il a deux moyens à sa disposition. Soit, il demande la création d’une nouvelle instance de la ressource. Soit, il possède le nom de la ressource et il demande l’établissement d’une liaison avec la ressource. Nous supposons ici que lors de la création d’une ressource, la liaison est aussi établie. Dans le modèle, la création d’une instance est effectuée par une usine « factory », la création d’une liaison est effectuée par un lieur « binder ». Tous deux étendent le gestionnaire et diffèrent uniquement dans la manière de fournir les ressources. Ils sont décrits ci-dessous.

• Comme mentionné précédemment, une usine permet la création de nouvelles ressources du typeAbstractResource. Une usine fournie l’interfaceResourceFactorydécrite à la figure 3.19. La méthodecreatedonne en résultat une référence sur la ressource créée. Ses arguments doivent contenir les informations requises par l’usine pour construire et gérer la ressource, comme par exemple la taille de la ressource à créer, la qualité de service requise, etc. Lorsque la méthodereleaseest invoquée sur la ressource, l’usine peut ne pas la détruire effectivement, mais conserver la ressource en vue d’une réutilisation future, on parle alors de groupe de ressource « pool ».

interface ResourceFactory extends ResourceManager {

AbstractResource create(...); }

FIGURE3.19 – InterfaceResourceFactory

La notion d’usine permet de modéliser de nombreux concepts d’un système d’exploitation. Par exemple, l’allocateur de mémoire physique ou virtuelle, l’ordonnanceur, etc.

• Posséder un nom sur une ressource ne signifie pas pouvoir interagir avec. La ressource peut par exemple être inutilisable ou inaccessible dans sa forme courante. Le rôle du lieur est de rendre accessible une ressource, son interfaceResourceBinderest donnée à la figure 3.20. La méthodebindmet en place les mécanismes permettant l’accès à la ressource. Le nom de cette ressource, permettant sa désignation, doit être passé en paramètre de la méthode. Elle retourne une référence permettant d’interagir avec la ressource. Le modèle permet potentielle- ment au lieur de retourner, non pas, une référence directe sur la ressource, mais une référence sur un composant intermédiaire. Ce qui offre la possibilité de placer une indirection, comme par exemple un mandataire ou un composant de synchronisation comme un moniteur.

3.3. Conclusion 65

interface ResourceBinder extends ResourceManager {

AbstractResource bind(...); }

FIGURE3.20 – InterfaceResourceBinder

Dans le modèle d’architecture, le lieur correspond, au nom près, aux usines à liaisons, que nous avons vu à la section 3.2.2 sur les liaisons flexibles. L’usine à liaisons est uniquement une utilisation concrète de l’interface du lieur et doit en toute rigueur étendre cette interface.

Application du modèle de ressources à la gestion du processeur

Pour illustrer l’utilisation du modèle de ressources, nous étudions comment il peut être instancié pour la gestion de l’activité dans un système. Comme nous l’avons vu au chapitre 2, l’activité dans un système est modélisée par des fils d’exécution qui sont couplés, par un ordonnanceur, sur un ou plusieurs processeurs. Les processeurs et les fils d’exécution peuvent être vus comme des ressources abstraites qui permettent de faire évoluer le système.

Un fil d’exécution offre l’interface Thread, voir la figure 3.21. La méthode run permet de démarrer l’activité par exemple sur une méthode. L’interface des fils d’exécution peut par exemple être enrichie de méthodes permettant de changer les paramètres d’ordonnancement.

interface Thread extends AbstractResource { void run(Method meth);

}

FIGURE3.21 – InterfaceThread

Un ordonnanceur est en fait une usine capable de créer des fils d’exécution et de les multiplexer sur une ressource de plus bas niveau, qui peut être le processeur ou un autre fil d’exécution. Ce deuxième cas est par exemple mis en œuvre avec les ordonnanceurs applicatifs, comme les « threads Posix ». L’interface d’un ordonnanceur, nomméeScheduler, est donnée à la figure 3.22. Comme nous pouvons le voir cette interface supporte la méthodecreate, héritée deResourceFactory

qui retourne un nouveauThread. Ici, cette méthode prend en paramètre le paramètre initial d’ordon- nancementSchedParamsqui peut être une priorité, une date limite, etc. L’interface de l’ordonnan- ceur peut aussi comporter des méthodes de synchronisations comme des méthodeswaitetnotify, mais nous y reviendrons en détail au chapitre 5 sur la réalisation.

3.3

Conclusion

Le modèle d’architecture s’applique à tous les systèmes qu’ils soient centralisés ou qu’ils soient répartis indépendamment de ou des machines sous-jacentes et du ou des langages de programmation. Le concept de liaison flexible permet de modéliser et d’implanter, généralement par la génération

interface Scheduler extends ResourceFactory {

Thread create(SchedParams params); }

FIGURE3.22 – InterfaceScheduler

automatique de composants de liaisons, l’ensemble des interactions que l’on rencontre dans un sys- tème ; appel système, remontée système, LRPC, RPC, etc. Le concept de domaine permet de modéli- ser l’ensemble des isolations comme les contraintes physiques avec la répartition et les contraintes de protection avec les processus. Le modèle de ressource facilite la compréhension du code et simplifie le développement des composants du système.

Dans le chapitre suivant, nous nous intéressons à l’implantation et à l’utilisation dans un système d’exploitation de ces différents concepts. Il est important de noter les interfaces définies dans ce chapitre sont directement exploitées dans l’implantation décrit au chapitre suivant.

Chapitre 4

Instanciation de l’architecture THINK

dans les systèmes d’exploitation

Dans le chapitre précédent, nous avons présenté l’architecture logicielle THINK. Nous nous in-

téressons maintenant à l’utilisation concrète de cette architecture pour la construction de systèmes d’exploitation. Nous étudions ici comment implanter de façon efficace le concept d’interface dans un langage qui n’en est pas pourvu et comment automatiser, via des outils, la génération des composants de liaisons. Même si l’architecture THINKest instanciée sur une architecture matérielle particulière, ici le POWERPC, cette instanciation est indépendante de l’architecture matérielle. Nous étudions aussi comment implanter les domaines en vue d’offrir la transparence requise. Nous voyons comment est réalisée la composition des différents composants d’un système et quels sont les outils de développe- ment associés. Cette implantation de l’architecture THINKest une proposition, cette architecture peut aussi être instanciée différemment.

4.1

Aperçu de l’implantation

L’architecture logicielle THINKrepose principalement sur le concept de composant, sur le concept d’interface et sur le concept de liaison flexible. Nous survolons brièvement dans cette section l’im- plantation, nous la décrivons en détail dans la suite du chapitre.