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 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.

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.