La gure 6.1 décrit les relations entre les classes qui gèrent le calcul local de l'application, l'ordonnancement des ré exes. Nous allons commencer par
Callback
setTask(in task : Task) : void
execute() : void
flash() : void cooperate() : void
CallbackManager
addPendingCallback(in callback : Callback) : void addWaitingTasks(in task : Task) : void
getNextFrame() : Frame
Frame
<<create>> Frame(in pendingCallbacks : Vector,in waitingTasks : Vector) getWaitingTasks() : Vector
getPendingCallbacks() : Vector isEmpty() : boolean
Scheduler release() : void
addCallback(in callback : Callback) : void wakeUp() : void
processFrame(in frame : Frame) : void
<<Interface>> Synchro myWait() : void myNotify() : void
Task
setCallback(in callback : Callback) : void releaseHand() : void launch() : void endOfCriticalSection() : void processTask() : void TaskPool getAvailableTask() : Task -task -owner -callback -scheduler -callbackManager 1..* -tasks
Fig. 6.1 Ordonnancement des ré exes, diagramme de classes décrire les responsabilités de ces diérentes classes.
L'interface Synchro est implémentée par la classe principale (celle qui contient le programme principal) de l'application. Elle permet de synchroni- ser le démarrage de l'ordonnanceur avec celui de l'application, a n qu'aucune modi cation n'intervienne tant que celui-ci n'est pas prêt.
6.3. L'ORDONNANCEUR ÉQUITABLE DES RÉFLEXES 169 La classe Callback représente un ré exe dé ni par l'utilisateur, lors de l'assemblage d'un ordonnançable. Sa méthode execute permet à l'ordonnan- ceur de lancer l'exécution du ré exe. C'est dans cette classe que sont dé nies les méthodes correspondant aux instructions utilisateur dont nous avons dé- ni la sémantique au chapitre précédent (voir section 5.4.1, page 141).
La classe Scheduler doit être instanciée par l'application principale. Elle crée les classes TaskPool et CallbackManager. C'est cette classe, qui étend la classe Java Thread, qui ordonnance l'exécution des ré exes les uns après les autres. L'instance de cette classe, créée au démarrage de l'application, fait également o ce d'interface entre le mécanisme d'ordonnancement représenté par les classes qui suivent et le reste de l'application.
La classe TaskPool est responsable de la gestion des threads Java qui serviront à exécuter les ré exes des ordonnançables en parallèle. Un certain nombre de threads Java sont créés dès le démarrage.
La classe CallbackManager est responsable de la gestion des ré exes en attente d'exécution, après une interruption par la méthode cooperate de la classe Callback de la manière décrite par la règle COOP ERAT E de la sémantique du calcul local (voir section 5.4.1, page 141), ou juste après leur déclenchement. Il correspond à l'ensemble S du prédicat utilisé pour décrire l'état de l'application dans la sémantique du calcul local.
La classe Task représente un thread Java, auquel l'ordonnanceur peut aecter un ré exe à exécuter.
En n, la classe Frame est une liste d'objets Task en attente et de ré- exes activés mais pas encore exécutés, et est utilisée pour construire un tour d'exécution des ré exes qui s'exécutent en parallèle.
La gure 6.2 décrit l'ajout d'un ré exe à la le d'exécution lors de l'ac- tivation d'un ordonnançable. Cet ajout est lié au déclenchement d'un or- donnançable, suite à la mise à jour d'un état de la manière décrite par la règle UP DAT E(s) de la sémantique du calcul local (voir section 5.4.1, page 141) ou conséquence d'une réplication de la manière décrite par la règle U P DAT E REP (s) de la sémantique du calcul distribué (voir section 5.4.2, page 148) . Si l'ordonnanceur est en sommeil faute de ré exes à exécuter, il est alors réveillé.
schedulable scheduler
addCallback
addPendingCallback
callbackManager
wakeUp
Fig. 6.2 Ajout d'un ré exe à la le de l'ordonnanceur lors du déclenchement de l'ordonnançable
donnanceur est réveillé, il eectue en boucle le traitement décrit.
Il construit l'objet frame correspondant au prochain tour d'exécution, et commence par exécuter les premiers blocs d'instructions de chaque ré exe en attente de démarrage, qui ont été ajoutés à la le d'attente lors du tour précédent selon la gure 6.2. Pour ce faire, il aecte chaque ré exe dans un objet task qui n'est pas déjà aecté à l'exécution d'un autre ré exe.
Puis il passe à l'exécution des blocs suivants des ré exes ayant appelé l'opération cooperate au tour précédent.
Si l'objet frame correspondant au tour suivant est vide, le scheduler se met en sommeil, et attend d'être réveillé par l'ajout d'un ré exe à exécuter.
6.4 Dynamique de l'application
La gure 6.4 représente la manière dont sont implémentés les diérents composants qui constituent l'application. Nous allons passer en revue ces composants, et la manière dont ils interagissent. La classe abstraite State est la classe permettant de dé nir les états de l'application (dé nition 4.5.1, page 113), l'extension NetState de cette classe permet de dé nir des états abonnés au réseau, qui pourront être mis à jour par des hôtes distants.
La classe DuplicatedStatesSet est une classe rassemblant des états du- plicata (voir section 5.3.1.2, page138). Un objet de cette classe n'est pas un état, mais une collection d'états se comportant de manière similaire et
6.4. DYNAMIQUE DE L'APPLICATION 171 scheduler callbackManager getNextFrame currentFrame getPendingCallbacks taskPool getAvailableTask currentCallback setTask
Ces opérations sont
effectuées pour chaque réflexe en attente,chaque cycle étant interronpu par un cooperate ou la fin du réflexe. getPendingTasks currentTask launch launch Idem cycle d’opérations précédent. execute cooperate endOfCriticalSection addWaitingTask execute cooperate endOfCriticalSection addWaitingTask
Fig. 6.3 Description d'un tour d'exécution
ayant le même père dans la hiérarchie en arbre des états. La classe State et la classe DuplicatedStatesSet ont donc néanmoins un certain nombre de méthodes et d'attributs en commun, dû au fait qu'ils sont tous deux des composants des états. Comme l'héritage multiple n'est pas possible en Java, nous avons utilisé pour uni er ces deux types l'interface StateComponent, et factorisé leurs traitement commun à la classe ConcreteStateComponent à qui les classes State et DuplicatedStateSet délèguent ces traitements.
La classe abstraite Schedulable est la classe qui représente les ordonnan- çables (dé nition 5.2.1, page 134) et ses extensions Behavior et Replication permettent de dé nir respectivement les ordonnançables comportementaux
Behavior Replication NetworkState Schedulable State
<<Interface>> StateAccess
setState(in stateCreationObserver : StateCreationObserver,in stateComponent : StateComponent) : void
StateCreationObserver
notify(in stateKey : String,in stateComponent : StateComponent) : void StateAccesList <<Interface>> StateComponent ConcreteStateComponent DuplicatedStateSet #state #keyStateSetters
Fig. 6.4 Architecture des composants, diagramme de classes
(les ordonnançables sans réplication associée) et les modèles de réplication. Les objets de type Schedulable correspondent au patron de conception clas- sique Observateur [46], et sont noti és lorsqu'ils sont instanciés, et qu'un des états observés (dé nition 5.3.3, page 140) est modi é. La gure 6.5 représente l'enchaînement d'appels qui mène à l'ajout d'un ré exe à la le d'attente de l'ordonnanceur lorsqu'un état est modi é et que certains de ses ordonnan- çables sont déclenchés. Cette séquence correspond à la règle UP DAT E(s) de la sémantique du calcul local que nous avons décrit au chapitre précé- dent (voir section 5.4.1, page 141). Elle sera alors suivie des séquences que nous avons déjà présentées pour décrire le fonctionnement de l'ordonnan- ceur ( gure 6.2, page 170, et gure 6.3, page 171). La gure 6.6 décrit le mécanisme d'envoi d'une mise à jour lorsqu'un modèle de réplication noti é est activé et que sa temporalité est véri ée. Cette séquence correspond à la production par le processus d'un événement R(s, S), tel que décrit dans la sémantique du calcul distribué (voir section 5.4.2, page 148) par les règles REP LICAT E U P DAT E(s).
La classe abstraite StateCreationObserver, étendue par les classes d'or- donnançables et les classes d'états, correspond également au patron de concep-
6.4. DYNAMIQUE DE L'APPLICATION 173 state callback scheduler schedulable execute update notify(state) activated, true realized, true addCallback
Ces opérations sont répétées pour chaque objet schedulable observant l’état mis à jour
Fig. 6.5 Mise à jour d'un état par un ré exe, diagramme de séquence
tion classique Observateur, et est noti é par l'application chaque fois qu'un état pour lequel il a exprimé un intérêt est créé ou détruit. Elle contient les listes d'associations dé nies dans les fabriques des composants, et les utilise pour aecter les états, les états duplicata, et les ensembles d'états duplicata dont la création lui a été noti ée dans les attributs adéquats. La gure 6.7 décrit ce mécanisme d'aectation aux composants de l'application qui ob- servent les créations. Cette séquence permet notamment d'implémenter les comportements des règles CREAT E(s) de la sémantique du calcul local (voir section 5.4.1, page 141) qui illustrent l'activation d'un ordonnançable instancié.
L'application crée les états et les ensembles d'états duplicata au travers d'un objet mapStorage qui est la carte de l'application. Nous étudierons plus en détail cette classe dans la partie suivante. Pour les états, ces noti cations interviennent donc lors de la création ou de la destruction de ses sous-états. Pour les ordonnançables, elles interviennent lors de la création des états utiles dans le calcul des conditions et des ré exes.
replication
state scope recipient comProperties
notify(state) send(replication,state, comProperties) send(state,comProperties) activated,true realized,true send(msg,recipient) processMessage(msg) sendMessage( netMessage, recipient)
cette séquence est répétée pour chaque recipient selectionné par le scope
Fig. 6.6 Réplication d'un état, diagramme de séquence