Nous pr´esentons la description des services de gestion des informations sur les objets d’une partition : descripteurs de processus et de m´ecanismes de communication et synchronisation, ainsi que compteurs de temps. Nous mod´elisons aussi les services utilis´es pour l’ordonnancement des processus et la mise `a jour des compteurs de temps.
8.2.1 Gestion des descripteurs
Les descripteurs d’objets sont des structures de donn´ees globales refl´etant ces objets, cr´e´ees au sein de l’ex´ecutif. Ils sont constitu´es d’attributs `a travers lesquels sont obtenues les informa-tions descriptives et dynamiques qui permettent de g´erer les objets. Nous appelons managers
les collections de descripteurs sur lesquelles s’appuient les modules de gestion des objets (cfFig. 8.7). Des op´erations typiques offertes par ces modules sont : le test d’existence d’un objet (c’est le cas du service CHECK_BOARD_ID utilis´e dans le mod`ele de la Fig. 8.6) ; la r´ecup´eration de l’´etat courant d’un objet (n´ecessaire pour d´efinir des services commeget blackboard status) ; ou la mise `a jour des attributs d’un objet (consistant parfois en des effets de bord sur les structures de donn´ees).
...
managers descripteurs d’une partition globale horloge ... ... ... ... ... ... ... ... ... ...Figure 8.7 – Gestion des objets sous forme de descripteurs.
Nous avons construit une premi`ere version de la mod´elisationSignal des services r´ealisant les op´erations mentionn´ees ci-dessus dans notre biblioth`eque de composants. Une seconde ver-sion est en cours de mise en œuvre. Dans la verver-sion termin´ee, nous avons utilis´e des m´ecanismes d’abstraction pour d´ecrire une partie des services. Les structures de donn´ees ont ´et´e d´efinies dans le langage C++. Les m´ethodes des classes correspondantes mettent alors en œuvre les acc`es aux attributs. Ainsi, le processus Signal repr´esentant une m´ethode donn´ee est d´efini comme une abstraction boˆıte noire de celle-ci. La version en cours est une ´evolution de la premi`ere. L’id´ee de base reste inchang´ee en ce qui concerne le d´ecoupage des structures de donn´ees, ainsi que les services d’acc`es aux structures. Seul le niveau de descriptionSignal change.
process CHECK_BOARD_ID =
( ? blackboardID_type board_ID; ! boolean present;
APEX_Blackboard_type board_OUT; )
spec (| (| board_ID --> present (d.1)
| {board_ID --> board_OUT} when present (d.2)
|)
| (| board_ID ^= present (s.1)
| board_OUT ^= when present (s.2)
|) |) pragmas
CPP_CODE "&o1 = GLOBAL_BLACKBOARD_MANAGER->BlackboardCheckID(&i1, &o2)" end pragmas
Figure8.8 – Mod`eleSignal d’un service externe avecpragma de liaison au code cible.
Pour illustrer les mod`eles de la premi`ere version, consid´erons la sp´ecification Signal de la figure 8.8 qui repr´esente le processus Signal correspondant au service CHECK_BOARD_ID. Ce service teste la pr´esence d’unblackboard dans le manager associ´e auxblackboards. Ceblackboard
est identifi´e par le signal d’entr´ee board_ID. En sortie, le bool´een present indique s’il a ´et´e effectivement enregistr´e dans lemanager. L’autre sortie, board_OUT, repr´esente la structure de donn´ees correspondant aublackboard si celui-ci est pr´esent.
Dans CHECK_BOARD_ID, la contrainte(s.1)traduit le fait qu’`a chaque invocation de ce ser-vice (indiqu´ee par la r´eception du signalboard_ID), le service retourne une r´eponse sous la forme d’un signal bool´een present. La propri´et´e (s.2) exprime que board_OUT est pr´esent unique-ment aux instants o`upresent porte la valeurvrai. Le signalboard_OUT d´enote la structure de donn´ees correspondant au blackboard recherch´e. Les d´ependances entre les entr´ees/sorties sont d´ecrites `a travers(d.1)et(d.2). Lespragmas sont introduits par le mot-cl´epragmas dans un processus Signal. Ici, le pragma est utilis´e dans une optique de g´en´eration de code. L’identi-ficateur CPP_CODE indique que ce pragma est interpr´et´e lorsque le langage d’implantation est C++. Les notations &i1,&o1 et&o2 encodent respectivement la premi`ere entr´ee, les premi`ere et seconde sorties. Enfin, tout le morceau de code entre guillemets (invocation d’une m´ethode
BlackboardCheckID sur GLOBAL_BLACKBOARD_MANAGER) repr´esente le fragment consid´er´e lors de la g´en´eration du code, et apr`es substitution des param`etres encod´es.
L’ensemble des services d’acc`es aux descripteurs a ´et´e d´efini suivant ce sch´ema. Ces ser-vices sont pr´esent´es de fa¸con d´etaill´ee dans [92]. D’un point de vue programmation, le langage C++ est bien adapt´e pour l’implantation des descripteurs et leurs fonctions d’acc`es. De par son orientation objet, il offre de bons concepts pour la d´efinition des structures de donn´ees en question. Une autre caract´eristique utilis´ee est la possibilit´e de r´ealiser des effets de bord sur les structures de donn´ees. Par exemple, si on consid`ere un pointeur qui indique `a chaque instant d’une ex´ecution le descripteur du processus actif, sa valeur peut ˆetre modifi´ee facilement. Ce genre de manipulation n’est pas possible enSignal, qui n’offre pas de pointeurs.
Par ailleurs, ce choix de mod´elisation qui repose en partie sur un langage externe (ici C++) est li´e `a la non disponibilit´e, au moment de la r´ealisation, d’une mise en œuvre des construc-tions Signal adapt´ees dans le compilateur. Les op´erations de manipulation de descripteurs n´ecessitent un moyen d’exprimer le parcours des collections de structures de donn´ees qu’on sou-haite consulter ou modifier. Ce genre de manipulation requiert la notion d’it´eration enSignal. Dans la version actuelle du compilateur, l’it´eration est mise en œuvre par une construction sp´eciale, appel´ee tableau de processus. Au sein de chaque instant logique, il y a une it´eration spatiale qui traite tous les ´el´ements du tableau (en l’occurrence, des processus Signal). Cela est caract´eris´e `a l’aide de la construction array[41]. L’exemple suivant d´efinit8 le signal vect
comme un vecteur de dimension n dont les ´el´ements repr´esentent la diagonale de la matrice carr´eemat, de mˆeme dimension :
array i to N
vect[i] := mat[i,i] end
Grˆace `a cette construction, nous pouvons d´efinir une nouvelle description des services de ges-tion des objets, enti`erement enSignal. Nous rappelons qu’un des objectifs de cette mod´elisation est de pouvoir acc´eder aux outils et techniques formels disponibles dansPolychronypour la v´erification et la validation. Dans des descriptions bas´ees sur des abstractions boˆıte noire comme celle de la Fig. 8.8, le nombre d’informations que le compilateur peut traiter est relativement limit´e. En particulier, le fragment de code C++ sp´ecifi´e dans lepragmaest vu comme une infor-mation externe. Ce qui veut dire qu’il ne sera pas concern´e par les v´erifications effectu´ees. Par exemple, pour le serviceCHECK_BOARD_IDtel que donn´e sur laFig. 8.8, seules les propri´et´es des signaux d’entr´ee/sortie sont prises en compte par le compilateur lors du calcul d’horloges (rien n’est connu du calcul effectu´e pour d´eterminer la valeur du signal presentpar exemple). Dans de pareilles situations, on doit donc s’assurer au pr´ealable de la correction du fragment de code utilis´e dans lepragma. Ici, les m´ethodes de classes C++ mises en œuvre sont en g´en´eral courtes et faciles. Cela r´eduit les risques d’erreurs de programmation mˆeme si cela reste insuffisant pour garantir enti`erement leur correction.
Toutes ces raisons motivent une ´evolution de la premi`ere solution vers la nouvelle, o`u davan-tage d’aspects seront appr´ehend´es en utilisant les outils et techniques formels dePolychrony.
8.2.2 Ordonnancement des processus
On rappelle que la politique d’ordonnancement est pr´eemptive et bas´ee sur les priorit´es. Chaque fois qu’un ordonnancement est d´eclench´e, le nouveau processus actif dans la parti-tion est celui qui a la priorit´e la plus forte et qui se trouve dans l’´etat ready. Pour d´ecrire l’ordonnancement et le choix du processus actif (cf. Fig. 8.9), nous consid´erons deux services suppl´ementaires : PROCESS_GETACTIVE et PROCESS_SCHEDULINGREQUEST (les autres primitives requises font partie des services APEX). Ces services sont d´ecrits, dans la premi`ere version de la biblioth`eque, de fa¸con analogue aux services de gestion de descripteurs (c’est-`a-dire, en utilisant des abstractions). Leurs interfaces sont donn´ees sur la Fig. 8.10 (le code complet se trouve en annexe).
• Le service PROCESS_SCHEDULINGREQUEST comporte un signal d’entr´ee sched_req et un signal bool´een en sortie, appel´esched_ok. Chaque r´eception du signal sched_req pro-voque un r´e-ordonnancement des processus de la partition. C’est un ´ev´enement qui est susceptible d’avoir pour origine soit une demande directe d’un processus ARINC, soit
descripteurs de processus ... ... ... ... ... processus prets^ a s’exécuter‘ ... ... ordonnancer(...) processus actif pid <− proc_actif(...) primitives ... ...
Figure8.9 – Module d’ordonnancement des processus.
un ´ev´enement quelconque interne `a la partition (par exemple, une tentative d’acc`es `a une ressource peut entraˆıner un r´e-ordonnancement). La sortie bool´eenne sched_okest produite instantan´ement. Elle est mise `a vrai lorsque le r´e-ordonnancement est effectu´e avec succ`es. Sinon, le signal porte la valeur faux (cela se produit notamment lorsque la partition interdit tout r´e-ordonnancement, ce qui est indiqu´e par la valeur de son niveau de verrouillage).
On peut observer que seul ce service n´ecessite des modifications si on d´ecide de changer de politique d’ordonnancement (exemples : R.M.S, E.D.F). Les services APEX mod´elis´es ne sont pas affect´es. Par cons´equent, leur r´eutilisation est pr´eserv´ee.
• Le servicePROCESS_GETACTIVEcomporte quatre signaux d’interface : une entr´eerequest
et trois sorties process_ID, statuset valid. Ce service est invoqu´e apr`es chaque de-mande de r´e-ordonnancement pour r´ecup´erer les informations sur le nouveau proces-sus actif de la partition. La pr´esence de l’´ev´enement request d´enote une demande de r´ecup´eration des informations. Celles-ci sont repr´esent´ees par les signauxprocess_IDet
status qui d´enotent respectivement l’identificateur et le statut (´etat, priorit´e, p´eriode, etc.) du processus actif. La derni`ere sortie, valid, indique la validit´e des deux autres sorties (pour le cas o`u aucun processus ne serait prˆet `a s’ex´ecuter - par exemple, dans le mode idle).
8.2.3 Gestion des compteurs de temps
La gestion du temps dans les ex´ecutifs temps r´eel repose souvent sur la gestion d’un temps lo-cal. Elle est r´ealis´ee `a travers des services, qui varient selon les ex´ecutifs. Ces services permettent g´en´eralement de : maintenir `a jour l’heure (sur une machine) ; effectuer des synchronisations (par exemple, suspension d’une tˆache pour une certaine dur´ee - service APEX timed wait) ; attendre des communications (en utilisant untime-out).
La mise `a jour des compteurs de temps d´eclench´es par les appels de services est r´ealis´ee au sein de l’ex´ecutif. Ainsi, `a chaque ex´ecution d’actions dans le processus actif, tous les comp-teurs ayant une valeur strictement positive sont d´ecr´ement´es de la dur´ee consomm´ee par cette ex´ecution. Lorsque la valeur d’un compteur devient nulle, le processus d´eclencheur est alors
process PROCESS_SCHEDULINGREQUEST = ( ? event sched_req;
! boolean sched_ok; )
spec (| (| sched_req --> sched_ok |) | (| sched_req ^= sched_ok |) |) ; process PROCESS_GETACTIVE = ( ? event request; ! ProcessID_type process_ID; ProcessStatus_type status; boolean valid; )
spec (| (| request --> valid
| request --> {process_ID, status} when valid |)
| (| request ^= valid
| process_ID ^= status ^= when valid |)
|) ;
Figure 8.10 – Interfaces des servicesprocess schedulingrequest etprocess getactive.
averti. Tous ces traitements sont r´ealis´es `a travers le service UPDATE_COUNTERS. Son interface, qui est illustr´ee sur la Fig. 8.11, comprend un seul signal d’entr´ee, dt. Celui-ci repr´esente la quantit´e de temps servant `a mettre `a jour les compteurs de la partition. En sortie, le service fournit le signaltimedout. Il s’agit d’un tableau de bool´eens dont la taille est au moins ´egale au nombre de processus de la partition. Pour chaque processus dans la partition, identifi´e par un certain entier pid, la valeur timedout[pid] indique si oui ou non le compteur de temps associ´e au processus est arriv´e en but´ee (dans ce cas,timedout[pid] est mis `a vrai, sinon il vautfaux). Tout expiration de temps concernant un compteur associ´e `a pid peut ˆetre alors d´etect´ee aux instants o`u on observe un basculement de timedout[pid] de la valeur faux `a la valeur vrai. Le signaltimedoutest ´emis r´eguli`erement par le noyau en direction des processus pour leur rendre compte de l’´etat courant des compteurs de temps actifs.
∗ ∗ ∗
Une liste compl`ete des services mod´elis´es est donn´ee dans l’annexe A. On trouvera par ailleurs une pr´esentation de ces services dans [92], o`u les propri´et´es d’interfaces sont donn´ees pour chaque service.