RE : RE - [SOS] Phénoméne bizard sur un schedulerarchi simp le...

[Romain LABBE]

Salut,

Merci pour ces explication Bombela mais je pige pas la demonstration,
puis je solicité tes éclaircissement ?


1/ Ld
Ca me rassure qu'il n'y ai pas que moi. Ce probleme est étrange mais
heureusement corrigé par les derniere version. Et une erreur dans le
script n'arrangai rien, ce probleme est réglé. Merci pour ces infos !


2/ Scheduler

J'ai aussi l'impression d'arrivé en limite de ressources mais je
n'arrive pas a me l'expliquer clairement et je n'aime pas ne pas
comprendre ce que je fais.

A/ Chaque thread s'execute 10ms toutes les 80ms...
-Tu fais donc une hypothese que le Thread consomme 10ms, soit !
-Pour la marge d'execution de 90ms, jusqu'ici je suis cette hypothese
(80ms endormis + 10ms d'execution) OK !
-En effet je peux donc caser 8 threads dans les 80ms a partir du moment
ou le thread courant vient de s'endormir OK !
- Si j'augment le nombre de thread en effet il va falloir plus de 80ms
pour refaire tourner le même thread !
Haa.... OK je commence a percevoir...
- En effet si j'augment le nombre de thread légérement cela ne devrait
pas se voir (Perf de l'œil, etc...) OK !
- Ok maintenant si on considere qu'un thread consomme moins de 10ms
forcement on peut executer bien plus de thread, (donc pas de saturation
au seuil théorique des 9 threads de l'hypothese des 10ms) OK !
- Oui le changement de contexte doit etre plus rapide que 10ms
- Ok pour un hypothese de temps d'execution a 0.5ms qui donne une limite
a 161 Thread etc....


J'ai pigé !

Du coup en fait lors de ma dégringolate de ressources, beaucoup de
thread a la bourre (explication du dessus) ne s'execute pas dans les
temps.
Du coup à un instanté T on se retrouve avec:
- Des thread en retard qui veulent acceder aux ressources (List et
screen) desleur réveil
- Mon thread d'affichage des info a l'ecran (toute les 50ms) il doit
donc verrouiller tres régulierement l'ecran. D’où l'augmentation en
fleche dans la liste des semaphores SCREEN
- Le temps de parcours de la liste augment avec le nombre de thread,
donc les thread consomme de plus en plus de temps, d’où l'augmentation
des waitq des semaphores de la LIST ce qui boucle la boucle...

Je pense avoir bien compris ce phenomene je vais essayer de le mettre en
evidence dans mon code !

GRAND MERCI Bombela pour tes explications, ca m'a permis d'avancer sur
ce probleme

A++

Romain



> -----Message d'origine-----
> De : sos-bounces at the-doors.enix.org 
> [mailto:sos-bounces at the-doors.enix.org] De la part de bombela at free.fr
> Envoyé : mercredi 13 septembre 2006 21:58
> À : SOS mailing-list
> Objet : RE - [SOS] Phénoméne bizard sur un schedulerarchi simp le...
> 
> 
> Salut,
> 
> Pour LD, j'ai rencontré ce problème, à l'époque où j'étais 
> encore sous windows... C'est bien une version particulière de 
> LD, qui se goure en sortie flat... Cette erreur n'apparissait 
> que sous windows, avec la même version de ld sous linux, je 
> crois que ça passait sans problème.
> 
> Pour ton sheduler, c'est effectivement essez interressant, 
> mais ça ressemble bien à un dépassement de ressource...
> 
> Chaques changement de thread se fait toutes les 10ms
> Bien, donc avec des threads qui s'execute 10ms toutes les 
> 80ms (pour prendre seulement les zballs), ça fait donc une 
> marge d'execution de 90ms... dans ces 90ms, tu peux caser 8 
> threads intercalé en executions...
> 
> Mails si tu augmente ??? Ben il vas falloire plus de temps 
> que les 80ms pour changer de thread... dans un certaine 
> limite, ça ne se verra pas.
> 
> Attention, il ne faut pas croire qu'a partir de 9 threads, 
> c'est saturé ! En effet, chaque thread effectue une action 
> tout petite, qui prend moins de 10ms !
> 
> Et comme le thread s'endors après sont action, le changment 
> de thread est très rapide...
> 
> Imagions que chaque thread prenne 1ms de temps cpus
> Avec nos 90ms, ça fait 81 threads pour commencer à saturer ! 
> Mais si le code fait 0.5ms ;) 161 threads... etc.
> 
> On peux donc imaginer que sur ton pc réel avec des 400 
> threads, c'est parce que chaque thread s'execute en moyenne 
> 90/400 = 0.255 ms
> 
> Je me trompe peux être dans les valeurs exactes (moi 
> fatigué), mais çe me semble logique.
> 
> @+
> 
> PS: J'ai merdouillé l'envois de ce mail en deux partie en 
> ratant le mailling list. J'ai donc envoyé proprement un 
> message complet. _______________________________________________
> Sos mailing list
> Sos at the-doors.enix.org 
> http://the-doors.enix.org/cgi-> bin/mailman/listinfo/sos
>