[SOS] Synchronisation

[Julien Lecomte]

Merci a tous pour avoir pris la peine de repondre. Je n'avais pas
compris le concept de noyau non preemptible. Maintenant, tout est plus
logique.

- Julien -


2008/4/16 Thomas Petazzoni <thomas.petazzoni at enix.org>:
> Le Wed, 16 Apr 2008 20:53:50 +0200,
>  David MENTRE <dmentre at linux-france.org> a écrit :
>
>
>  > Non pas besoin de synchro car comme dit dans sa description[1] SOS est
>  > un « noyau de type monolithique, interruptible, non préemptible ». En
>  > d'autres termes, quand tu es en mode noyau ton code ne peut pas être
>  > interrompu sauf quand tu le décide (« non préemptible ») sauf par un
>  > handler d'interruption (« interruptible »).
>  >
>  > Par contre, il y a besoin de synchros entre les handlers
>  > d'interruptions et le reste du noyau. Un moyen simple est de
>  > désactiver toutes les interruptions temporairement
>  > (sos_disable_IRQs()).
>
>  Rien à ajouter, c'est tout à fait exact.
>
>  Pour ajouter quand même quelque chose à ce message, je peux préciser
>  que le noyau Linux était également à l'origine non préemptible: une
>  fois qu'une tâche exécutait du code en mode noyau, alors elle ne
>  pouvait pas être préemptée par une autre tâche. Au moment où le support
>  SMP a été introduit, les développeurs ont choisi la solution simple du
>  Big Kernel Lock (plus connu sous le nom de BKL) : un gros verrou pris
>  quand on commence l'exécution du code noyau, et relâché quand on
>  repasse en mode utilisateur. Grâce à ce verrou, deux processeurs
>  différents ne pouvaient pas exécuter en même temps du code noyau.
>  Ainsi, le code noyau n'avait pas besoin de se préoccuper de la
>  synchronisation (en dehors de la synchro entre contexte processus et
>  contexte d'interruption). Mais évidemment, en termes de performances,
>  ce n'est pas idéal. D'abord en matière de scalabilité: plus on a de
>  CPUs, plus on a de chances d'avoir des CPUs qui ne font rien en
>  attendant qu'un autre CPU finisse d'exécuter son code noyau. Et en
>  terme de réactivité: si une tâche de plus haute priorité devient prête
>  pour l'exécution, alors elle doit quand même attendre que la tâche
>  actuelle termine son appel système, alors que cette dernière tâche est
>  peut-être de plus basse priorité, ce qui entraîne une augmentation de
>  la latence.
>
>  Enfin, à noter que KOS, le projet "père" de SOS, est lui totalement
>  préemptible. Dans le cas de SOS, David et moi avions fait le choix de
>  ne pas utiliser la préemption, afin de rendre le système plus simple.
>  Mais du coup, le système est peut-être trop différent de l'état de
>  l'art actuel, et les articles laissent donc de coté des préoccupations
>  actuelles importantes.
>
>  Bonne journée,
>
>  Thomas, en direct de http://embeddedlinuxconference.com/
>  --
>  Thomas Petazzoni, thomas.petazzoni at enix.org, http://thomas.enix.org
>  Jabber, thomas.petazzoni at jabber.dk
>  Toulibre, http://www.toulibre.org - APRIL, http://www.april.org
>  Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
>
> _______________________________________________
>  Sos mailing list
>  Sos at the-doors.enix.org
>  http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos
>
>