<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD><TITLE></TITLE>
<STYLE>
body, table, tr, td, p {font-family: Verdana;font-size:12px;margin: 0px 0px 0px 0px}
.bgtabl {BACKGROUND-REPEAT: no-repeat}
</STYLE>
</HEAD>
<BODY bgProperties="fixed" bgcolor="#FFFFFF" background="http://flashimg.club-internet.fr/flashmail/vide.gif">
<br>
bonjour ,<br>
<br>
j'ai compris le pb de la terminaison de thread , mais pourkoi dans sos au niveau de kos-sys <br>
si on enleve les boucles for (;;) le systeme plante ? je crois c un defaut de page <br>
<br>
oui si tu a des modifs à proposer je suis tres interressé !! <br>
<br>
a+<br>
<br>
<br>----Message d'origine----
<br>>De: sos-request@the-doors.enix.org
<br>>Sujet: Lot Sos, Vol 35, Parution 3
<br>>A: sos@the-doors.enix.org
<br>>Date: Thu, 7 Apr 2005 12:00:07 +0200 (CEST)
<br>>
<br>>Envoyez vos messages pour la liste Sos à
<br>> sos@the-doors.enix.org
<br>>
<br>>Pour vous (dés)abonner par le web, consultez
<br>> http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos
<br>>
<br>>ou, par email, envoyez un message avec 'help' dans le corps ou dans le
<br>>sujet à
<br>> sos-request@the-doors.enix.org
<br>>
<br>>Vous pouvez contacter l'administrateur de la liste à l'adresse
<br>> sos-owner@the-doors.enix.org
<br>>
<br>>Si vous répondez, n'oubliez pas de changer l'objet du message afin
<br>>qu'il soit plus spécifique que "Re: Contenu du digest de Sos..."
<br>>
<br>>
<br>>Thèmes du jour :
<br>>
<br>> 1. Re: Re: Evolution ? (David Decotigny)
<br>>
<br>>
<br>>----------------------------------------------------------------------
<br>>
<br>>Message: 1
<br>>Date: Wed, 06 Apr 2005 18:43:14 +0200
<br>>From: David Decotigny <david.decotigny @free.fr="">
<br>>Subject: Re: [SOS] Re: Evolution ?
<br>>To: SOS mailing-list <sos @the-doors.enix.org="">
<br>>Message-ID: <425411A2.9040104@free.fr>
<br>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
<br>>
<br>>
<br>>Bonjour,
<br>>
<br>>D'abord, pour répondre à Xavier qui a sûrement été beaucoup influencé
<br>>par http://www.acm.org/classics/oct95/ , oui : dans SOS il y a quelques
<br>>goto. Et ce n'est pas fini, il y en aura quelques autres encore (pas
<br>>trop, rassure-toi). Ce n'est pas que je garde des vieilles habitudes du
<br>>basic, c'est juste que dans certaines fonctions ça aide à la lisibilité
<br>>du code et à la maintenabilité aussi. Pour les fonctions qui doivent
<br>>fabriquer des choses en cours de route et qui doivent les "défabriquer"
<br>>en cas d'erreur, c'est très pratique, ça évite les redondances de code
<br>>(source d'oublis en cas de modif) ou les imbrications de if/else.
<br>>L'ideal eût été d'avoir un systeme d'exceptions au niveau du langage....
<br>>c'est là que Ada eût été tres apprecie.
<br>>
<br>>weisenhorn.geoffroy@club-internet.fr wrote:
<br>>> Mais j'ai une question comment fait on dans sos pour terminer un thread
<br>>> il n'y a pas de thread Trash
<br>>> comme dans Koalys ?
<br>>
<br>>Non et c'est volontaire. Dans SOS, les threads *noyau* n'ont le droit de
<br>>terminer que de leur propre initiative (ie terminaison dite "synchrone"
<br>>: appel a sos_thread_exit). La difficulte d'un systeme de terminaison
<br>>assynchrone (ie ce que tu cherches) est la suivante. Imagine qu'on
<br>>termine un thread qui possede un mutex. Dans ce cas, ceux qui sont en
<br>>attente du mutex ne seront jamais reveilles ? Evidemment, pour cette
<br>>question, il y a une reponse systematique : pour tout thread noyau qui
<br>>possede l'acces a une ressource, celle-ci est mise dans une "liste des
<br>>ressources possedees par le thread", et on appelle un callback sur
<br>>chacune de ces ressources quand le thread est termine. Je ne suis pas
<br>>sûr que cette solution ne soit pas source d'interblocage, mais a vue de
<br>>nez ça fait ce qu'on veut : ca marche bien meme en cas de terminaison
<br>>assynchrone. Techniquement, c'est une solution envisageable a faible coût.
<br>>
<br>>Dans SOS, on n'a pas implanté ça. Mais on n'en n'a pas vraiment besoin
<br>>car à terme (je ne sais pas encore quand), ce genre de choses se fera
<br>>via l'espace utilisateur. De la meme facon que dans Unix : si un
<br>>processus P1 veut terminer un autre processus P2, un "signal" est envoye
<br>>a P2, ce qui correspond a l'execution d'une routine user dans le
<br>>processus P2, et cette routine peut faire ce qu'elle veut, en
<br>>particulier faire exit(). Bref, meme avec ce genre de mecanisme
<br>>assynchrone (au niveau *user*), ca se termine toujours par une
<br>>terminaison synchrone du thread *noyau* ET dans de bonnes conditions.
<br>>Car en effet, au final c'est un thread utilisateur en mode utilisateur
<br>>qui demande a SE terminer, donc on est sûr qu'il ne possede aucune
<br>>*synchro noyau* bas-niveau (sinon c'est que le noyau se vautre qqpart :
<br>>un thread noyau ne doit posseder aucune synchro noyau [ksynch] quand il
<br>>repasse en mode user) : le thread noyau "possede" juste les *synchro
<br>>user et ressources user* (en gros, je parle des "file descriptors"). Et
<br>>celles-ci, on sait les gerer parfaitement en cas de terminaison puisque
<br>>"exit" doit deja savoir les gerer. Bref, avec cette solution, on n'a pas
<br>>de cas particulier a gerer au niveau du noyau : juste un cas d'appel a
<br>>"exit" user tout a fait normal.
<br>>
<br>>Voila le pourquoi de la chose. Mais encore une fois, le code de SOS
<br>>devrait pouvoir servir de base a faire des experiences. Le but n'est pas
<br>>de proposer un OS "ficelé" prêt à etre installe et a regarder "tourner".
<br>>C'est que vous compreniez comment ça marche pour changer des bouts,
<br>>etudier, et... faire mieux ! Je pense que cette "fonctionnalite" qui,
<br>>selon vous, "manque", ce serait un bon exercice pour voir les problemes
<br>>qui peuvent se poser (s'il en existe).
<br>>
<br>>Tiens, pendant que j'y suis, voici une autre idee de truc interessant a
<br>>regarder : au niveau de kmem_vmm, on gere des regions classees par
<br>>adresses croissantes. Mais ce classement se fait de façon naïve, ie par
<br>>des listes ! Une idee d'amelioration serait d'utiliser des arbres, on
<br>>gagnerait enormement en complexite (O(log n) contre O(n)) donc en
<br>>rapidité. Si on ne l'a pas fait, c'est pour que le code de SOS ne soit
<br>>pas trop chargé avec une implantation des arbres binaires (p.ex
<br>>splay-trees comme dans KOS) très efficace, mais finalement pas
<br>>fondamentale puisqu'on peut obtenir la meme fonctionnalite avec des
<br>>listes. Dans l'article 7.5 vous pourrez remarquer le meme "probleme" : a
<br>>deux endroits, des listes classées auraient pu avantageusement etre
<br>>remplacées par des arbres.
<br>>
<br>>Je pourrais donner d'autres idees de modifs. Si des gens sont
<br>>interesses, nous serions ravis de rajouter leurs contributions sur le
<br>>site de sos !
<br>>
<br>>Bonne journee,
<br>>
<br>>--
<br>>David Decotigny -- http://david.decotigny.free.fr
<br>>
<br>>
<br>>------------------------------
<br>>
<br>>_______________________________________________
<br>>Sos mailing list
<br>>Sos@the-doors.enix.org
<br>>http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos
<br>>
<br>>
<br>>Fin de Lot Sos, Vol 35, Parution 3
<br>>**********************************
<br>>
</sos></david.decotigny></body></html>