-Trace deadlock avec deux consommateurs, deux producteurs et un tampon de taille 1.
+Pseudo-trace deadlock avec deux consommateurs, deux producteurs et un tampon de taille 1.
+-----------------------------------------------------------------------------------------
-Buffer vide -> C1 et C2 sont en attente (suspendus).
- -> P1 rentre en section critique, depose et notifie un thread, mettons P2
-Buffer plein -> P1 se met en attente, P2 a été notifié mais le buffer est plein, donc
- P2 en attente.
- -> donc C1, C2, P1, P2 sont en attente
- et aucune notification ne sera faite pour les réveiller.
+Buffer vide -> C1 et C2 se mettent en attente dans la file (C1, C2).
+ -> P1 rentre en section critique et P2 se met en attente soit (P2, C1, C2).
+ P1 depose et notifie a un unique thread en attente.
+ Le dernier en attente est P2 donc P2 est notifié.
+Buffer plein -> P2 sort de la file d'attente (C1, C2) et entre en SC, P1 se met en attente (P1, C1, C2).
+ Or le buffer est plein, donc P2 se met en attente dans la file (P2, P1, C1, C2).
+ -> donc C1, C2, P1, P2 sont en attente dans la file (P2, P1, C1, C2)
+ et aucune notification ne sera faite pour les sortir de la file.
-> deadlock.
Solution: faire un notifyAll() en sortie de SC dans le buffer pour s'assurer que un
- thread d'un type différent du type courant sortant du moniteur est notifié
- (Consommateur -> Producteur ou Producteur -> Consommateur)
+ thread d'un type différent du type courant sortant du moniteur est également notifié
+ (Consommateur -> Producteur ou Producteur -> Consommateur) et sort de son attente.
+
+N.B. : On suppose que la mise en attente des threads dans le moniteur est une file.
+ Mais même si c'est une autre structure de données, la possibilité de deadlock
+ demeure.
repositories / TD_SR.git / blobdiff