[SOS] Re: Evolution ?

[David Decotigny]

Bonjour,

D'abord, pour répondre à Xavier qui a sûrement été beaucoup influencé 
par http://www.acm.org/classics/oct95/ , oui : dans SOS il y a quelques 
goto. Et ce n'est pas fini, il y en aura quelques autres encore (pas 
trop, rassure-toi). Ce n'est pas que je garde des vieilles habitudes du 
basic, c'est juste que dans certaines fonctions ça aide à la lisibilité 
du code et à la maintenabilité aussi. Pour les fonctions qui doivent 
fabriquer des choses en cours de route et qui doivent les "défabriquer" 
en cas d'erreur, c'est très pratique, ça évite les redondances de code 
(source d'oublis en cas de modif) ou les imbrications de if/else. 
L'ideal eût été d'avoir un systeme d'exceptions au niveau du langage... 
c'est là que Ada eût été tres apprecie.

weisenhorn.geoffroy at club-internet.fr wrote:
> Mais j'ai une question comment fait on dans sos pour terminer un thread 
> il n'y a pas de thread Trash
> comme dans Koalys ?

Non et c'est volontaire. Dans SOS, les threads *noyau* n'ont le droit de 
terminer que de leur propre initiative (ie terminaison dite "synchrone" 
: appel a sos_thread_exit). La difficulte d'un systeme de terminaison 
assynchrone (ie ce que tu cherches) est la suivante. Imagine qu'on 
termine un thread qui possede un mutex. Dans ce cas, ceux qui sont en 
attente du mutex ne seront jamais reveilles ? Evidemment, pour cette 
question, il y a une reponse systematique : pour tout thread noyau qui 
possede l'acces a une ressource, celle-ci est mise dans une "liste des 
ressources possedees par le thread", et on appelle un callback sur 
chacune de ces ressources quand le thread est termine. Je ne suis pas 
sûr que cette solution ne soit pas source d'interblocage, mais a vue de 
nez ça fait ce qu'on veut : ca marche bien meme en cas de terminaison 
assynchrone. Techniquement, c'est une solution envisageable a faible coût.

Dans SOS, on n'a pas implanté ça. Mais on n'en n'a pas vraiment besoin 
car à terme (je ne sais pas encore quand), ce genre de choses se fera 
via l'espace utilisateur. De la meme facon que dans Unix : si un 
processus P1 veut terminer un autre processus P2, un "signal" est envoye 
a P2, ce qui correspond a l'execution d'une routine user dans le 
processus P2, et cette routine peut faire ce qu'elle veut, en 
particulier faire exit(). Bref, meme avec ce genre de mecanisme 
assynchrone (au niveau *user*), ca se termine toujours par une 
terminaison synchrone du thread *noyau* ET dans de bonnes conditions. 
Car en effet, au final c'est un thread utilisateur en mode utilisateur 
qui demande a SE terminer, donc on est sûr qu'il ne possede aucune 
*synchro noyau* bas-niveau (sinon c'est que le noyau se vautre qqpart : 
un thread noyau ne doit posseder aucune synchro noyau [ksynch] quand il 
repasse en mode user) : le thread noyau "possede" juste les *synchro 
user et ressources user* (en gros, je parle des "file descriptors"). Et 
celles-ci, on sait les gerer parfaitement en cas de terminaison puisque 
"exit" doit deja savoir les gerer. Bref, avec cette solution, on n'a pas 
de cas particulier a gerer au niveau du noyau : juste un cas d'appel a 
"exit" user tout a fait normal.

Voila le pourquoi de la chose. Mais encore une fois, le code de SOS 
devrait pouvoir servir de base a faire des experiences. Le but n'est pas 
de proposer un OS "ficelé" prêt à etre installe et a regarder "tourner". 
C'est que vous compreniez comment ça marche pour changer des bouts, 
etudier, et... faire mieux ! Je pense que cette "fonctionnalite" qui, 
selon vous, "manque", ce serait un bon exercice pour voir les problemes 
qui peuvent se poser (s'il en existe).

Tiens, pendant que j'y suis, voici une autre idee de truc interessant a 
regarder : au niveau de kmem_vmm, on gere des regions classees par 
adresses croissantes. Mais ce classement se fait de façon naïve, ie par 
des listes ! Une idee d'amelioration serait d'utiliser des arbres, on 
gagnerait enormement en complexite (O(log n) contre O(n)) donc en 
rapidité. Si on ne l'a pas fait, c'est pour que le code de SOS ne soit 
pas trop chargé avec une implantation des arbres binaires (p.ex 
splay-trees comme dans KOS) très efficace, mais finalement pas 
fondamentale puisqu'on peut obtenir la meme fonctionnalite avec des 
listes. Dans l'article 7.5 vous pourrez remarquer le meme "probleme" : a 
deux endroits, des listes classées auraient pu avantageusement etre 
remplacées par des arbres.

Je pourrais donner d'autres idees de modifs. Si des gens sont 
interesses, nous serions ravis de rajouter leurs contributions sur le 
site de sos !

Bonne journee,

-- 
David Decotigny -- http://david.decotigny.free.fr