[Kos-dev] Reentrance de reschedule : un solution ?

[Hlide]

> > 1)  Thomas : tu proposes que les BH soient effectués SYSTEMATIQUEMENT
dans
> > un thread séparé de celui interrompu. Ce changement de contexte s'avère
> > totalement inutile si on peut garantir que le BH ne sera pas bloquant -
on a
> > donc une perte d'efficacité.
>
> desole d'avoir insiste, mais j'aime bien savoir pourquoi on choisit
> telle ou telle solution. effectivement, le fait que le BH soit execute
> directement apres l'interruption permet d'avoir un traitement qui se
> fait tout de suite apres, et qui n'est pas reporte a plus tard. ca evite
> effectivement une certaine inertie au systeme.
>

Non mais tu as raison d'insister, ça nous aide à creuser un peu plus la
question.

> > 2) David propose que les BH soient non bloquants et qu'il existe une
> > troisième classe qui peut être bloquante : les threads mandataires ou
> > proxies. C'est au programmeur de décider si il utilisera un BH ou un
proxy.
> > Les BH sont donc plus efficaces. Quant aux threads mandataires, on les
> > utilise en dernier recours.
>
> la solution de d2 me semble effectivement une bonne solution. cela m'a
> tjs semble etre une bonne solution, mais il me semblait qu'on pouvait
> simplifier en n'utilisant que des threads mandataires. or, cela ne
> convient pas au niveau performances.
>

Ce qui m'ennuie surtout c'est que pour chaque BH on doit changer de
contexte. Alors qu'à priori, une seule tâche suffirait par processeur :
cette tâche, d'après David, se chargerait d'exécuter le BH le plus
prioritaire. Si une tâche venait à bloquer, on la passe dans une liste des
BH en attente et on passe au BH suivant jusqu'à ce qu'il en ait plus. Le
thread mandataire se mettra en attente. Le réveil de ce thread
s'effectuerait soit en ajoutant de nouveaux BH, soit en débloquant la
ressource responsable de l'attente d'un BH. Le nombre de changement de
contexte est donc réduit au strict minimum. Reste que chaque BH utilise une
pile et c'est là que tout se corse en fin de compte...

> > 3) Si on sait que le code du programmeur exécuté dans un proxy n'est pas
> > systématiquement bloquant ou qu'il l'est très rarement - on a alors
> > effectivement une solution pas optimale.
>
> effectivement si le code est pas souvent bloquant, cela cree des temps
> de latences inutiles.

Oui, c'est pourquoi THEORIQUEMENT il vaudrait mieux que ce cas soit traité
comme une exception.

> > 4) Si le programmeur décide d'utiliser un BH avec une ressource
bloquante,
> > c'est la catastrophe, car on va effectivement bloqué une tâche victime.
>
> euh oui, mais la je crois qu'on doit considerer que le systeme est
> correctement programme, et que si ce cas arrive, c'est que le
> programmeur est stupide.

M'oui :-)

> > Qouiqu'il en soit, je suis tenté - comme David - de penser que les BH
> > doivent être non-bloquants. Pourquoi ? il est hors de question qu'un
> > périphérique soit bloqué à cause un BH bloqué.
>
> euh c'est pas le peripherique qui est bloque a cause d'un BH bloque,
> mais plutot le thread interrompue !
>

Ben si le périphérique passe par un seul BH, et si le BH est bloqué, comment
fait le périphérique pour récupérer son BH ? Bon admettons que l'on peut
créer autant de BH que le périphérique en veut. Imaginons que son premier BH
est bloqué et qu'un deuxième BH pour le même périphérique est crée : on
pertube alors l'ordre chronologique des traitements. Pire, s'il devait
exister une cohérence ou une dépendance, cela peut pertuber le périphérique
dans son fonctionnement d'autant qu'il attend peut-être un aquittement.

> > - réduire les changements de contexte entre le BH et les tâches des
victimes
> > au strict minimum.
> > - n'avoir recours à un thread séparé que s'il y a un réel blocage.
>
> > Par contre, un BH pourrait avoir sa propre pile. Il s'exécuterait dans
un
> > premier temps dans la tâche victime. Si un blocage se présente, une
liste
> > d'attente des BH bloqué prend en charge le BH en récupérant sa pile et
on
> > restaure la pile d'origine à la tâche victime pour que celle-ci puisse
> > continuer quand ce sera son tour. Dans tous les cas, à la terminaison
d'un
> > BH la pile d'origine est restituée à la tâche victime.
> > C'est une solution qui semble à cheval entre celle de Thomas et celle de
> > David.
>
> en fait ta solution est plutot simple en theorie : on a que des BHs, qui
> peuvent etre bloquants. (on pourrait conserver la possibilite d'avoir
> des threads mandataires mais je vois pas trop l'interet). lorsqu'un BH
> devient bloquant, on le transforme en quelque sorte en thread
> mandataire.
>
> a priori, cela semble plutot simple en theorie, et en pratique a
> premiere vue ca me parait faisable. un peu complexe certes, mais
> faisable.
>

Je me pose surtout la question de savoir quel pourrait être la gestion
optimale. Je ne me suis pas encore posé la question sur la faisabilité et la
facilité (parfois trompeuse) d'une telle gestion. Parce que la complexité je
la vois aussi du côté des primitives bloquantes sur des ressources : le
comportement va différer s'il s'agit d'un BH qui va se bloquer (la pile du
BH qui n'est pas celle de la tâche victime).

Dans un premier temps, faire des BH non bloquant me parraît la première
chose à faire (et la plus simple aussi je crois).

J'aimerais aussi troqué le terme BH pour DSR qui me parraît plus en phase
avec les ISR, si ca ne vous dérange pas. D'ailleurs j'utilisais tout au
début ce terme non pas pour "delayed service routine" mais pour "defered
service routine" ce qui au fond revient au même (c'était au WE-II peut-être
?).

A la prochaine.