Mécanismes de synchronisation

Vous pouvez lire les slides de cours pour voir les détails, mais voici le résumé des principes en quelques lignes.

• Il est nécessaire d'avoir des mécanismes de synchronisation
  • Dès lors que plusieurs threads se partagent le processeur et que ces threads peuvent utiliser les mêmes ressources, il est nécessaire d'avoir des mécanismes de synchronisation afin de décider de la propriétés des ressources.

(à compléter)

A. Questions de cours

La majorité des réponses aux questions sont dans le cours ou dans le rappel du cours donné au début de cette page, c'est voulu. Les questions suivent à peu près l'ordre du cours, elles sont simples, mais vous avez besoin de comprendre le cours pour y répondre :-) Quand une question vous demande si quelque chose est vrai ou faux, ne répondez pas juste "oui" ou "non », mais justifiez vos réponses avec une petite phrase. Le but de ces questions est d'évaluer vos connaissances, donc plus vous êtes précis, mieux c'est.

1. Lors de la précédente séance, nous avons ajouté 3 allocateurs de mémoire dynamique : malloc_ustack() pour les piles user des threads, kmalloc() pour les objets du noyau et malloc() pour les segments de l'application. Est-ce que les 3 opérations d'allocation citées sont concernés par les synchros ? Justifiez.
2. Un verrou est une mémoire à deux états, quelles sont les deux opérations de l'API de gestion ?
3. Nous avons vu 4 mécanismes permettant de réaliser une "séquence atomique" pour les opérations read-modify-write. Que signifie "séquence atomique"? Est-ce que cela a un rapport avec les interruptions ? Parmi les 4 solutions, laquelle allons nous utiliser et pourquoi ?
4. Si deux threads A et B veulent prendre un verrou libre V et effectue la séquence LL/SC sur le verrou V : A exécute LL en premier et voit le verrou libre, puis B exécute à son LL et voit aussi le verrou libre? Les deux threads vont faire un SC. Qui va pouvoir prendre le verrou en fonction de l'ordre des SC?
5. Nous avons vu le problème ABA, est-ce que la solution proposée par le MIPS pour gérer les sections critiques à ce problème ? Si non, est-ce que cela a un coût matériel ?
6. Les threads avaient 3 états différents : READY (en attente du processeur), RUNNING (en cours d'exécution) et DEAD (définitivement stoppé et effaçable). Ils ont désormais 2 nouveaux états : WAIT (en attente d'une ressource) et ZOMBIE (définitivement stoppé mais en attente qu'un autre thread récupère la valeur de retour). Quelles sont les deux nouvelles fonctions de l'API kernel des threads permettant respectivement de passer de l'état RUNNING à l'état WAIT et de l'état WAIT à l'état READY ? Est-ce que ces fonctions sont utilisables par l'application ?
7. Les fonctions thread_join() et thread_exit() fonctionnent de manière coordonnée, thread_join() permet à un thread de se mettre en attente de l'exécution de thread_exit() par un autre. Est-ce qu'un thread peut attendre simultanément plusieurs threads en même temps ?
8. Un thread passe de l'état RUNNING à l'état ZOMBIE lorsqu'il appelle thread_exit(), quand passe-t-il à l'état DEAD ?
9. Le contenu de la structure struct thread_s (c'est-à-dire les champs qui la compose est définie dans le fichier kernel/kthread.c. En conséquence cette structure n'est utilisable que par les fonctions de ce même fichier kernel/kthread.c. A l'extérieur, les fonctions ne manipulent que des pointeurs sur la structure de type thread_t (défnis par

B. Travaux pratiques

Commencez par récupérer le code de source de la séance s7.tgz

Pour la partie pratique, vous allez devoir programmer un peu. Les premières questions sont assez faciles, les dernières un peu moins, faites ce que vous pouvez. Je ne vous demande pas de faire tous les exercices, d'autant qu'il n'y aura pas de correction pour le moment (faute de temps). Le but est de vous «forcer» à entrer dans le code et même des petites modifications suffisent. Les exercices sont classés par niveau de difficultés supposées (on est jamais à l'abri de surprise)

En préalable de tous les exercices, quelques questions sur le code. Dans le répertoire s7 vous trouvez le répertoire 01_synchro qui contient le code complet des nouveaux mécanismes de synchro. Cela a un impact sur hcpua.S pour les spinlocks, kthread.[ch] pour la gestion des deux nouveaux états WAIT et ZOMBIE, en particulier les fonction thread_wait et thread_notify, et évidemment thread.[ch] pour l'ajout des appels systèmes.

01_synchro
├── Makefile
├── common
│   ├── debug_off.h
│   ├── debug_on.h
│   ├── errno.h          // codes d'erreur des appels système
│   ├── esc_code.h       // séquence d'échappement ASCII 
│   ├── list.h
│   ├── syscalls.h
│   └── usermem.h
├── kernel
│   ├── Makefile
│   ├── harch.c
│   ├── harch.h
│   ├── hcpu.h
│   ├── hcpua.S
│   ├── hcpuc.c
│   ├── kernel.ld
│   ├── kinit.c
│   ├── klibc.c
│   ├── klibc.h
│   ├── kmemory.c
│   ├── kmemory.h
│   ├── ksynchro.c       // mutex et autres implémentation
│   ├── ksynchro.h       // mutex et autres protopypes
│   ├── ksyscalls.c
│   ├── kthread.c
│   └── kthread.h
├── uapp
│   ├── Makefile
│   └── main.c
└── ulib
    ├── Makefile
    ├── crt0.c
    ├── libc.c
    ├── libc.h
    ├── memory.c
    ├── memory.h
    ├── thread.c
    ├── thread.h
    └── user.ld

B.1.