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

[Thomas Petazzoni]

> Imaginons que le timer appelle reschedule, que ca entraine un
> *mauvais* #DF (suppr du thread) : dans ce cas #DF fout le thread en
> DELETED : il faut bien qu'a un moment ou un autre un reschedule soit
> fait pour prendre en compte ce DELETED, et ceci *avant* le
> "iret". Comme on sait pas ou le reschedule a ete interrompu, il faut
> le relancer depuis le debut.
> D'un autre cote tu as raison : c'est sur qu'on n'a pas besoin d'un
> vrai reschedule dans le handler #DF. On a juste besoin de
> "dont_need_another_reschedule = 0;". Mais bon, comme ca coute pas
> beaucoup plus cher de rendre reschedule reentrant, autant le faire (ca
> peut peut-etre servir dans d'autres cas bizarres).

effectivement tu as raison, au moins on sera sur qu'on aura fait
reschedule et que le thread sera pas reelu.

> Voui. Faudrait regarder le coup du set_current de plus pres. Etudier
> la question comme reschedule : doit-il etre appele dans le #DF ?...

effectivement le probleme du set_current_thread doit etre etudie avec
beaucoup de precision, on avait deja eu des problemes de consistence
avec ce satane truc, qu'on avait simplement resolu : "set_current_thread
a toujours mettre juste avant le retour".

juste avant le retour, c'est peut etre un peu flou nan ?

> Je pense comme tu l'as dit plus loin que ca n'a rien de
> revolutionnaire. Mais que ca permet de nous donner un peu de recul sur
> ce dont on a besoin pour la liaison avec tout ce qui est disque, swap,
> etc.. Personnellement, ca m'a permis d'y voir plus clair. C'est
> surtout ca l'interet que j'ai vu dans ces docs.

effectivement ca me permet d'avoir une vue plus globale sur le sujet, et
de mieux prevoir les choses. je pense qu'on discutera de
l'implementation a faire dans KOS a bordeaux.

> Oui, avec kos, le noyau est preemptif en UP.

ouah la classe :o)

> Imagine ce que donne le remplissage de result_passwd qd 2 threads
> l'executent "simultanement" (meme en UP) => caca. Donc getpwuid n'est
> pas reentrante. D'ou la presence de getpwuid_r a laquelle on fournit
> en parametre le struct passwd a remplir => version reentrante.

effectivement la c'est clair et net que ca va foutre le bordel ! mais
nous on sait coder, hein :o)

> Imagine qu'on est en SMP, sans cli/sti autour des spinlocks. Puisque
> on est en SMP, on a de /vraies/ variables de spinlocks (/vraies/
> attentes actives). Imaginons qu'un thread met le spinlock a USED pour
> proteger une section critique. Imagine que sur le meme processeur une
> interuption soit levee pdt cette section critique (car pas de sti) et
> que, pour proteger une section critique vis a vis des autres
> processeurs, elle veuille posseder le *meme* spinlock => elle va
> bloquer a l'infini car le spinlock est deja pris par le processeur !
> Donc quand on prend un spinlock en SMP, il faut que les interruptions
> soient interdites en local. Sinon deadlock.

okay la je comprends mieux. pourrais-tu mettre a jour draft-0 avec
toutes les precisions apportees dans ce mail (concernant l'exemple d'un
machin non reentrant, concernant cette explication, et d'autres) ?

> Attention, dans un bottom half, pas de blocage possible. Ce qui
> differencie une ISR d'un BH, c'est que l'ISR est protegee des
> interruptions ("un BH est interruptible"). Cependant, comme le BH
> n'est pas associe a un thread propre (on ne peut pas dire que le
> thread qui a ete interrompu ait ete choisi deterministiquement), il
> est hors de question que ce BH puisse bloquer en attente sur
> ressource, pas plus que l'ISR ne peut le faire.

je ne comprends pas trop la relation de cause a effet existant entre 'le
BH n'est pas associe a un thread propre' et 'il est hors de question que
ce BH puisse bloquer en attente sur ressource'.

> Dans le sens Linux, le BH est en effet une extension de l'ISR. Ce dont
> parle le draft-0, c'est que, en plus des BH (et des wait queues
> Linux), on ait recours a un "thread mandataire" (proxy) destine a
> executer les traitements (associes aux ISR) susceptibles de bloquer en
> attente sur ressource. On pourrait presque les appeler "BH de 2eme
> niveau".

je suis d'accord sur le principe, mais pas sur la terminlogie : pourquoi
thread mandataire ? pourquoi proxy ?

> Je parle les IRQ (interruptions asynchrones). Les exceptions sont
> synchrones et resultent d'une faute processeur : on n'a *surtout* pas
> interet a les masquer. D'ailleurs, elles ne sont pas masquables
> (tiens, j'en suis meme pas si sur ;).

ok, ca je m'en doutais, mais ce ne m'explique pas la necessite de ton
systeme des ipl, pourrais-tu le preciser ?

> Non, et je n'ai jamais pretendu ca. Mais moi ca m'a permis d'y voir
> plus clair.

ok on est d'accord, j'ai bien compris le contenu des docs. 

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/