• Aucun résultat trouvé

CONTR ˆ OLE DE LA CHARGE 87 – que la derni`ere requˆete de la file doit ˆetre remplac´ee (REPLACE) ;

Java n’est pas un langage pour le

6.4. CONTR ˆ OLE DE LA CHARGE 87 – que la derni`ere requˆete de la file doit ˆetre remplac´ee (REPLACE) ;

– que la taille de la file doit ˆetre augment´ee (SAVE).

6.4.3 Assurer les contraintes temporelles

Les param`etres attach´es aux objets ordonnan¸cables permettent de r´ealiser une analyse de faisabilit´e d’un syst`eme compos´e uniquement de tˆaches p´eriodiques ou sporadiques.

Ils permettent ´egalement d’automatiser des traitements en cas de non respect des contraintes qu’ils sp´ecifient. Un Schedulablequi d´epasse son budget ou qui ne respecte pas son ´ech´eance est th´eoriquement rendu in´eligible, c’est-`a-dire que ses activations futures seront ignor´ees. Il est ´egalement possible de sp´ecifier lors de la cr´eation des ReleasePara-meters deux AEH qui seront ordonnanc´es lors du d´epassement du coˆut pour l’un et lors du d´epassement de l’´ech´eance de la tˆache pour le second. Il est ´eventuellement possible dans le code de cesAEH de r´etablir l’´eligibilit´e de la tˆache fautive. Notons que cette der-ni`ere n’est pas interrompue, sauf si lehandlerassoci´e poss`ede une plus forte priorit´e : elle est alors pr´eempt´ee et peut ˆetre interrompue de mani`ere asynchrone (voir section 6.5).

La sp´ecification propose ´egalement la classeProcessingGroupParameters, qui permet d’assigner des ressources communes (date de d´emarrage, p´eriode, pire temps d’ex´ecution,

´ech´eance) `a un groupe d’objets Schedulable. Comme pour les ReleaseParameters, il

est ´egalement possible de fournir des AEH activ´es automatiquement en cas de violation

de ces param`etres.

Toutefois, dans un cas comme dans l’autre, cela suppose que la RTJVM surveille la

consommation de temps processeur de chaque tˆache. Or, comme cela n’est pas possible avec tous les OSs, il s’agit d’une possibilit´e optionnelle de la sp´ecification, que nous

ap-pellerons dans la suite surveillance du temps CPU ou «temps CPU» .

La d´etection et le traitements des fautes temporelles sur une RTJVMqui ne supporte

pas le temps CPU a fait l’objet d’un travail pr´eliminaire `a cette th`ese pr´esent´e dans [MM05, MM06].

Si la RTJVM supporte le temps CPU, les ProcessingGroupParameters permettent

l’´ecriture, au niveau logique, d’un serveur de tˆache. Ce mod`ele reste tr`es insuffisant car il est trop permissif, il ne permet pas de choisir la politique de service, et ne comporte pas les outils n´ecessaires `a l’int´egration du serveur dans l’analyse de faisabilit´e. Ces points

sont expliqu´es dans [BW03]. Tr`es r´ecemment, Andy Wellings et MinSeong Kim ont

propos´e de modifier la s´emantique de cette classe afin d’en pr´eciser la signification dans un environnement multiprocesseurs, et en ont d´efini des extensions pour l’´ecriture de serveurs de tˆaches ap´eriodiques [WK08].

Cette absence de support portable pour les m´ecanismes avanc´es d’int´egration de tˆaches ap´eriodiques a motiv´e notre travail : fournir des adaptations des m´ecanismes de service et de vol de temps creux implant´es dans l’espace utilisateur afin d’en assurer la portabilit´e

88 CHAPITRE 6. LA SP ´ECIFICATION JAVA POUR LE TEMPS R ´EEL (RTSJ)

6.4.4 Analyse de faisabilit´e

Les m´ethodes permettant de v´erifier la faisabilit´e du syst`eme se trouvent dans la classe Scheduler. Toutes les tˆaches ne sont pas concern´ees. Le m´ecanisme repose sur un enregistrement pr´ealable des tˆaches qui doivent ˆetre prises en compte lors de l’analyse. L’analyse en elle-mˆeme utilise les propri´et´es d´efinies par lesSchedulingParameterset les ReleaseParameters. La fa¸con dont sont pris en compte lesProcessingGroupParameters n’est pas sp´ecifi´ee ni d’ailleurs l’algorithme utilis´e pour d´eterminer la faisabilit´e d’un syst`eme de tˆaches les utilisant. Rien n’indique non plus s’il doit s’agir d’un test suffisant, n´ecessaire ou n´ecessaire et suffisant.

Les param`etres m´emoire des tˆaches devraient ´egalement entrer en consid´eration, mais il n’est pas expliqu´e de quelle mani`ere.

Notons ´egalement que les SporadicParameters ne comportent pas de champs

per-mettant de sp´ecifier la date de la premi`ere activation, contrairement aux PeriodicPara-meters. Il faudra donc consid´erer que la tˆache peut ˆetre activ´ee d`es l’instant initial.

La sp´ecification ne pr´evoit pas non plus de sous classe `aReleaseParametersincluant le param`etreJi. Il faudra donc utiliser unSporadicParameterspour les tˆaches pr´esentant une gigue d’activation.

Si le support pour ´ecrire les algorithmes d’analyse de faisabilit´e est bien pr´esent dans

RTSJ, il semble insuffisamment sp´ecifi´e et document´e. Nous reviendrons sur ce point dans la section 9.3.

6.5 Interruption et transfert de contrˆole asynchrone

Une limitation du mod`ele de thread de Java est l’impossibilit´e d’interrompre ou de

suspendre un autrethread que lethread courant. Il existe bien les m´ethodessuspend()et stop()mais elles sont d´epr´eci´ees car elle peuvent laisser la m´emoire dans un ´etat incoh´e-rent.RTSJ propose d’utiliser le m´ecanisme des exceptions pour pallier a cette limitation

en introduisant l’exceptionAsynchronouslyInterruptedException.

Un thread peut alors explicitement ˆetre d´eclar´e comme pouvant ˆetre interrompu en utilisant lors de sa conception l’interface Interruptible. Cette interface poss`ede deux m´ethodes :

– run(AsynchronouslyInterruptedException e) pouvant lever l’exception d’inter-ruption ;

– interruptAction(AsynchronouslyInterruptedException e).

La premi`ere contient le code relatif `a l’ex´ecution du thread, la seconde le code qu’il faudra ´eventuellement ex´ecuter avant la terminaison du thread s’il est interrompu.

Afin de faciliter l’utilisation de ce m´ecanisme, la sp´ecification fournit ´egalement la

classeTimedqui ´etendAsynchronouslyInterruptedExceptionet qui poss`ede la m´ethode

6.5. INTERRUPTION ET TRANSFERT DE CONTR ˆOLE ASYNCHRONE 89 de l’objet logic, et l`eve l’exception d’interruption asynchrone `a l’expiration d’un compte `a rebours associ´e `a la classe Timed.

Notons enfin qu’un thread ainsi interrompu ne peut pas ˆetre repris. Ce m´ecanisme

ne permet donc pas de se substituer `a l’ordonnanceur pour suspendre momentan´ement une tˆache. Des exemples d’utilisation de ce m´ecanisme sont fournis dans les annexes page clxix.