[Kos-dev] Sémaphore

[David Decotigny]

Bonjour,

Cyril Dupuit wrote:
> Par contre, dans l'article sos de février, vous annoncez que pour faire 
> un noyau préemptif, il faut utiliser des variables globales. En 

Aïe, alors il y a eu contre-sens. Non, si un noyau possede des variables 
globales, alors il n'est pas necessairement preemptif ! Par contre, le 
fait qu'il y ait des variables globales dans un noyau preemptif 
necessite une protection de ces variables.

> regardant le code de Linux, j'ai vu qu'ils utiliaient lock_kernel et 
> unlock_kernel (un spinlock).

Je pense que c'est ce qu'ils appellent le "Big Kernel Lock" (BKL). C'est 
un verrou qui protege toutes les ressources globales du noyau qui n'ont 
pas (encore) leur propre verrou. Au debut (noyaux 2.0), il etait utilise 
en SMP pour etre sur qu'il n'y a qu'un seul processeur qui est en mode 
noyau a 1 instant donne. En effetn, a l'origine (noyaux 0.x, 1.x), Linux 
comme la plupart des Unix (et comme SOS) etait non preemptible ; et ce 
BKL a permis de rester en non-preemptible meme en SMP. Ca rendait sa 
conception beaucoup plus simple.

Graduellement, avec le 2.4 puis surtout le 2.6, le but a ete de rendre 
le noyau preemptible (plus efficace en SMP, plus reactif meme en UP). 
Pour ça, on souhaite que chaque ressource globale soit protegee par son 
propre verrou, et pas que 234234243 ressources globales  soient 
protegees par *le* BKL. Bref, l'objectif actuel est de virer le BKL du 
source. Comme ça, si un processeur demande une ressource, il se retrouve 
bloqué *uniquement* quand *la* ressource qu'il demande est detenue par 
un autre processeur. A contrario, avec le BKL, un processeur peut 
bloquer sur le BKL alors qu'il demande la ressource rA tandis qu'un 
autre processeur utilise une autre ressource rB qui n'a rien à voir 
(elles sont en effet protegees par un unique verrou : le BKL).

Bref, l'objectif des noyaux "recents" est de virer le BKL, c'est-a-dire 
de faire de la synchro "grain fin". Les problemes de synchro faisant 
intervenir un comportement temporel, c'est un travail de tres longue 
haleine tres delicat a faire (peut-etre parce que l'esprit humain a 
quelques difficultes a manier le temps).

Dans KOS, le but est de s'attaquer au probleme du SMP le plus tot 
possible pour eviter un refactoring geant lie au passage UP -> SMP. Ca 
passe par la mise en place de synchros grain fin le plus tot possible. 
Dans SOS par contre, pas besoin de BKL vu que le noyau est non preemptif 
par construction et qu'on ecarte d'emblee le support SMP.

Bonne journee,

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