[SOS] Synchronisation

[n5]

Beaucoup de  ressources globles du système ne sont pas protegées en acces exclusif.  En apparence, 3 groupes d'activités peuvent donc y acceder librement: les threads noyau, les threads utilisateur (les process) via les traps, et les services d'interruptions. C'est donc l'anarchie, en apparence.

Or le principe de pilotage des activités est fondé sur deux reègles essentielles:
- Règle 1  les threads utilisateurs accedent a ces ressources globales de manière non interruptible. Ceci interdit donc des dérangements par tous les autres groupes d'activités.
- Règle 2  les services d'interruption s'interdisent de lancer une nouvelle activité si l'activité interrompue tournait en mode noyau. (voir code fonction "sos_thread_prepare_irq_switch_back")

La seconde règle suffit a elle seule pour régler la concurrence d'acces aux données globales entre les threads utilisateurs et les thread noyau. La premiere règle résoud la concurrence entre les services d'interruption et les treads utilisateurs.

Il reste a régler la concurrence entre les threads kernel et les services d'interruption.

En fait, si les services d'interruption manipulent les données globales via des acces protégés en exclusivite, alors le probleme disparait.  La plupart des services d'interruption de Sos (clavier, ligne serie et ide) sont très basiques et , de maniere tres résumée, se limitent a activer une thread eventuellement en attente sur un sémaphore (c'est la cas des 3 interruptions standards : clavier, ligne série et ide). Ils utilisent des données globales qui sont protégées en acces exclusif. Il existe pourtant une exception, en apparence: c'est le timer. En particulier, ce timer a un role essentiel : le réveil de thread. Ce réveil transite par sleep_timeout, sos_thread_force_unblock et arrive sur la fonction sos_sched_set_ready qui, elle, manipulera les données globales et cette dernière fonction n'est pas protégé des accès concurrents. Dans ce cas particulier, les données menacées sont  les tables d'activites.. 
Si aucune thread noyau ne manipule les tables d'activités , notre probleme disparait encore.  Il existe pourtant un exemple typique d'accès a ces tables d'activités, depuis des threads noyau: c'est le service de mise en veille limitée (sos_thread_sleep).  Ce service accède aux tables d'activités , dans le cadre de la replanification -fonction sos_reschedule- mais, cette dernière fonction est utilisée en mode exclusif (depuis l'appelant). L'utilisation est donc satisfaisante.
IL existe cependant une trace fossile d'un accès voyou a ces tables d'activités. Par exemple, l'ancienne thread  "MouseSim"  (il me semble bien qu'elle n'est plus utilisée). Dans son coeur , elle utilise une fonction comme sos_create_kernel_thread. Et cette fonction appelle le service sos_sched_set_ready qui n'est pas protégé...  

Il semble donc bien que, malgrès les apparences, le système Sos règle de manière satisfaisante les conflits d'accès. 
Le défaut du système se présente plutôt au niveau de la documentation. En particulier, il faudrait préciser les restrictions a appliquer aux handlers d'interrution en ce qui concerne les accès aux ressources globales (par exemple:  interdire les allocations memoires).

Au fait:  tout ceci n'est qu' hypothèses. Si quelqu'un peut confirmer ou corriger ...

La question que je me pose maintenant, c'est l'utilité de la règle 1: pourquoi le trap systeme est il ininterruptible ?
Connaissant la règle 2, les taches utilisateurs ne peuvent entrer en conflit sur les ressources globales qu'avec les services d'interruption. Or  , il me semble bien, (mais ceci reste a confirmer) que ces services d'interruptions n'utilisent que des ressources qui sont en acces exclusif (essentiellement ,depuis les fonction sos_kwaitq_wakeup, sos_sema_up).  Tant que ces services d'interruption restent basiques (et en particulier ne jouent pas avec l'allocation de mémoire), il me semble que la règle 1 pourrait tomber. Le système gagnerait en réactivité ..... ?

Christian Guerineau.





----------
De : 	Julien Lecomte
Date :	dimanche 27 avril 2008 21:06
A :	SOS mailing-list
Objet :	Re: [SOS] Synchronisation

Qu'en est-il des kernel threads? Si un kernel thread manipule des
donnees globales, qu'il est interrompu par le timer, et qu'a l'issue
de l'execution de l'ISR du timer, l'ordonnanceur decide qu'un autre
processus doit prendre son tour. N'y a-t-il pas un probleme de
synchronization la? Il semble qu'il devrait y avoir des appels a
sos_disable_IRQs un peu partout (y compris dans sos/physmem.c, mais je
n'en vois aucun)

Amicalement,
Julien


2008/4/16 David MENTRE <dmentre at linux-france.org>:
> Bonjour,
>
>
>
>  "Julien Lecomte" <julien.lecomte at gmail.com> writes:
>
>  > J'étais en train de regarder le code de SOS, et me demande comment est
>  > faite la synchronisation a l'intérieur du noyau. Par exemple, la
>  > fonction sos_physmem_ref_physpage_new (sos/physmem.c) modifie la liste
>  > nonfree_ppage (données globales). Il n'est pas impossible que le code
>  > de cette fonction soit interrompu en plein milieu, puis executé par un
>  > autre processus, en mode noyau. Ne devrait-il pas y avoir une section
>  > critique la, ou je n'ai rien compris?
>
>  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()).
>
>  Amicalement,
>  david
>
>  Footnotes:
>  [1]  http://sos.enix.org/fr/SOSOverview
>
>  --
>  GPG/PGP key: A3AD7A2A David MENTRE <dmentre at linux-france.org>
>   5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
>
_______________________________________________
Sos mailing list
Sos at the-doors.enix.org
http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos