[SOS] Synchronisation

Thomas Petazzoni thomas.petazzoni at enix.org
Mer 16 Avr 22:02:30 CEST 2008


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://the-doors.enix.org/pipermail/sos/attachments/20080416/417497d9/attachment.pgp 


Plus d'informations sur la liste de diffusion Sos