[SOS] temps réel

[David Decotigny]

Bonsoir,

Selon Christophe Lucas <c.lucas at ifrance.com>:
> On Mon, 2004-09-20 at 22:07, Fabian Rami wrote:
> > Est-il possible de tranformer la base pour utiliser sos comme un système
> > temps réel ?

Il y a 50000 definitions de "temps-reel". Pour moi quand on dit "temps-reel", je
pense a la citation de Stankovic qui dit en gros "Real time computing systems
are defined as those systems in which the correctness of the system depends not
only on the logical result of computation, but also on the time at which the
results are produced". Bref, pour moi ca veut dire que j'ai a la fois a prouver
une correction fonctionnelle de mon systeme, mais aussi une correction
temporelle (respect de contraintes temporelles telles que des echeances, une
gigue d'activation mximale donnee, etc.).

Ce qu'on peut dire c'est que, relativement a la definition precedente
(la plus stricte il me semble), oui *pour l'instant* SOS pourrait, en l'etat,
etre qualifie de "temps-reel". MAIS j'insiste sur le "*pour l'instant*". Car en
effet, pour l'instant (ie article 3), tous les elements de l'OS s'executent en
un temps deterministe puisqu'il n'y a que des operations en temps constant
effectuees par le processeur une fois que physmem est initialisee.

Mais les choses vont se gater avec l'article 5 qui presente un algo d'allocation
memoire. Cet algo est relativement simple (enfin attendez quand meme d'avoir lu
l'article) mais definir une borne sup sur le temps d'execution d'une allocation
risque d'abord d'etre difficile, mais surtout TRES pessimiste
(il y a une boucle difficile a borner qqpart, vous verrez). Or avec la def du
TR precedente, si on veut prouver qu'on respecte toutes les contraintes de
temps, il faut etre capable de savoir de combien de temps CPU on a besoin *au
pire* pour executer chaque operation.

Avec cette alloc memoire, donc, on peut rayer de la carte le TR strict, car le
temps d'exec /pire-cas/ d'une alloc risque d'etre pas raisonnable du tout
(genre plusieurs secondes) meme si /en moyenne/ on voit qu'on peut faire
plusieurs millions d'alloc par seconde. Une seule solution pour s'en sortir  et
continuer de faire du TR avec SOS : utiliser l'allocateur lors de
l'initialisation de l'OS seulement, et ne plus l'utiliser une fois que les
taches TR seront lancees. Comme ca pas de surprise. C'est d'ailleurs souvent
comme ca qu'on fait du RT strict avec des RTOS qui proposent un allocateur
memoire (certains n'en proposent pas : seules les alloc par le compilo sont
autorisees). Je ne
connais pas en effet d'algo d'alloc memoire qui exhibe un comportement pire-cas
raisonnable (cf http://www.irisa.fr/aces/doc/ps02/ecrts02.ps.gz).

Mais bon, tout ca s'applique pour la def stricte de TR. Et il faut nuancer car
pas mal de RTOS s'autorisent certaines libertes sur le determinisme et le
bornage en temps pire-cas de leurs primitives, en particulier de leurs
primitives d'alloc.

Selon Christophe Lucas <c.lucas at ifrance.com>:
>
http://www.google.fr/search?hl=fr&ie=UTF-8&q=OS+temps+r%C3%A9el&btnG=Recherche+Google&meta=

Pour des sites universitaires de reference en TR et en pire-cas il y a(vait)
l'Universite d'York et une en Suede (j'ai oublie) pour le pire-cas. Pour le
reste : cf refs donnees dans http://david.decotigny.free.fr/rt/intro-ordo/ (le
reste c'est pourri au niveau du style et avec plein de trucs faux, mais c'etait
un premier jet). Et il y a aussi (pub) :
http://www.irisa.fr/aces/doc/Auteur/Isabelle.Puaut.english.html ;)

Bonne soiree,

--
d2