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

[Thomas Petazzoni]

> 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.

> 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.

> 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.
 
> 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.

> 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 !

> - 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.

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com
ICQ : 34937744
Projet KOS : http://kos.enix.org