Changes between Version 9 and Version 10 of AS6-TME-B7


Ignore:
Timestamp:
Apr 11, 2022, 7:56:17 PM (2 years ago)
Author:
franck
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AS6-TME-B7

    v9 v10  
    99
    1010- **Il est nécessaire d'avoir des mécanismes de synchronisation**
    11   - 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.
     11  - 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é des ressources.
    1212
    1313(à compléter)
     
    2525
    2626
    27 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.
     271. 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ées par les synchros ? Justifiez.
    2828{{{#!protected ------------------------------------------------------------------
    2929'''
     
    3737'''
    3838}}}
    39 1. 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 ?
     391. 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 ?
    4040{{{#!protected ------------------------------------------------------------------
    4141'''
     
    4343'''
    4444}}}
    45 1. 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?
     451. 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. En fonction de l'ordre des SC, qui va pouvoir prendre le verrou ?
    4646{{{#!protected ------------------------------------------------------------------
    4747'''
     
    4949'''
    5050}}}
    51 1.  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 ?
     511.  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 ?
    5252{{{#!protected ------------------------------------------------------------------
    5353'''
     
    5555'''
    5656}}}
    57 1. 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 ?
     571. 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 ?
    5858{{{#!protected ------------------------------------------------------------------
    5959'''
     
    6767'''
    6868}}}
    69 1. Un thread passe de l'état RUNNING à l'état ZOMBIE lorsqu'il appelle `thread_exit()`, quand passe-t-il à l'état DEAD ?
     691. Un thread passe de l'état RUNNING à l'état ZOMBIE lorsqu'il appelle `thread_exit()`. Quand passe-t-il à l'état DEAD ?
    7070{{{#!protected ------------------------------------------------------------------
    7171'''
     
    9191'''
    9292}}}
    93 1.
     931. Les appels système peuvent ne pas pouvoir rendre les services qu'on leur demande, soit parce que les ressources ne sont pas disponibles, soit parce que les arguments sont erronés. Pour informer l'utilisateur de l'échec, ils rendent souvent un code d'erreur, lequel est aussi présent dans une variable globale nommée `errno`. Pourquoi, est-ce qu'il y a un problème avec `errno` dans le cas des applications multi-thread ?
     94{{{#!protected ------------------------------------------------------------------
     95'''
     96 *
     97'''
     98}}}
     991. Le système définit `errno` de la façon suivante : `#define errno *__errno_location()`, que fait la fonction `errno_location()` ? Comment cela peut régler le problème ?
    94100{{{#!protected ------------------------------------------------------------------
    95101'''
     
    110116Les exercices sont classés par niveau de difficultés supposées (on est jamais à l'abri de surprise)
    111117
    112 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.
     118En 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 fonctions `thread_wait` et `thread_notify`, et évidemment `thread.[ch]` pour l'ajout des appels systèmes.
    113119{{{
    11412001_synchro
     
    156162
    157163
    158 == B.1.
     164== B.1. Mécanisme des barrières
    159165
    160166
     167En cours, nous avons vu le mécanisme de base, le spinlock (ou busylock) réalisant une prise de verrou par attente active et le mutex ayant aussi comme finalité de prendre un verrou, mais cette fois sans attente active, en organisant une liste d'attente des threads. Notez que nous avons présenté les spinlocks pour le noyau et les mutex pour l'utilisateur, mais il est parfaitement possible d'avoir des spinlocks en mode utilisateur (LL et SC ne sont pas des instructions privilégiées) et mutex en mode noyau.
     168
     169Il existe d'autres mécanismes de synchronisation, par exemple, les sémaphores, les variables de conditions, les read-write lock, ou les barrières de synchronisation. Nous allons, ici nous intéresser aux barrières.
     170
     171Une barrière de synchronisation est utilisée pour synchroniser les étapes de calculs réalisés par plusieurs threads. Supposons que l'on souhaite exécuter deux threads en parallèle et que l'on veuille attendre que les deux aient terminé leur travail avant de recommencer un travail. Il faut que les deux threads se donnent rendez-vous à la fin de leur calcul.
     172