EnglishCommencer

Section critique et mutex

La section critique et l'exclusion mutuelle, ce qu'une bonne solution doit garantir, l'opération atomique, le mutex POSIX (lock, unlock, trylock), l'attente active contre le blocage et le grain du verrou.

  • 27 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Section critique : de quoi s'agit-il ?

    Voir la réponse

    Partie du code qui lit ou modifie une donnée partagée et qu'un seul thread à la fois doit exécuter.

    Elle se définit par la donnée qu'elle touche, pas par la fonction : l'affichage d'un message n'en fait pas partie, la mise à jour d'un solde partagé oui.

  • Deux threads exécutent chacun cette fonction, sans verrou, avec solde à 100 au départ. Quelles valeurs finales sont possibles ?

    ```c
    int solde = 100;

    void *depot(void *arg) {
    int tmp = solde;
    tmp = tmp + 50;
    solde = tmp;
    return NULL;
    }
    `

    • 150 ou 200
    • Toujours 200
    • Toujours 150
    • 100, 150 ou 200
    Voir la réponse

    150 ou 200

    Si les deux threads lisent 100 avant que l'un écrive, chacun écrit 150 et un dépôt est perdu. Si l'un finit avant que l'autre lise, on obtient 200. La valeur 100 est impossible : chaque thread écrit au moins 150.

  • Une bonne solution au problème de la section critique garantit l'…, la … (un thread hors section ne bloque pas les autres) et l'… (aucun thread n'attend indéfiniment).

    Voir la réponse

    Une bonne solution au problème de la section critique garantit l'exclusion mutuelle, la progression (un thread hors section ne bloque pas les autres) et l'attente bornée (aucun thread n'attend indéfiniment).

    Les trois sont nécessaires : un verrou jamais rendu respecte l'exclusion mais viole la progression, et un thread toujours doublé viole l'attente bornée.

  • Exclusion mutuelle : de quoi s'agit-il ?

    Voir la réponse

    Garantie qu'à tout instant au plus un thread se trouve dans une même zone de code protégée.

    C'est ce qui empêche les entrelacements fautifs : tant qu'un thread est dans la zone, les autres attendent à la porte.

  • Un virement verrouille le mutex, vérifie le solde, appelle sleep(2) pour simuler une validation bancaire, modifie le solde puis déverrouille. Avec dix virements simultanés, le programme dure vingt secondes. Que corriger ?

    • Remplacer le mutex par une attente active
    • Retirer le mutex, puisque le sommeil ralentit déjà les threads
    • Créer un mutex différent pour chaque virement
    • Sortir la validation du verrou, qui ne couvre plus que le solde
    Voir la réponse

    Sortir la validation du verrou, qui ne couvre plus que le solde

    Pendant le sommeil, le verrou est tenu pour rien : les neuf autres virements attendent. Le verrou doit couvrir la section critique et elle seule. Un mutex par virement n'exclurait plus rien : chacun prendrait le sien sans gêner les autres.

Réviser ce deck