Bonjour tout le monde
Peut-t'il y avoir un "context switch" (fr: commutation de contexte) quand on fait un mutex_lock().
Si oui est-ce que cela explique le problème du deadlock ? Mais alors à quoi sert le mutex_lock() ?
Sinon quand a-t-on le problème du deadlock ?
Merci d'avance
OuiEnvoyé par Chirs
Non
Un mutex sert a rendre exclusif le code qui suit l'acquisition du mutex, généralement l'utilisation d'une ressource.
Imaginez que vous écrivez un fichier. Vous devez vous assurer que vous êtes le seul qui écrivez ledit fichier tout le long de la procédure d'écriture. Si une autre personne écrivait en même temps que vous, vos données seraient mixées, aléatoirement, un coup vos données seraient écrites, un coup l'autre.
(Dans le cas des fichiers, ce n'est pas un mutex, mais un verouillage de fichier; c'est la même mécanique logique)
D'une manière plus abstraite, imaginez une barrière à la porte d'entrée d'une entreprise, et qu'il faut un badge pour entrer sur site.
A l'entrée pend un badge, et il n'existe qu'un seul badge. Par conséquent, vous pouvez prendre le badge et entrez.
Une fois à l'intérieur, vous pouvez faire ce que vous voulez, sans avoir à vous souciez des autres, vous êtes seul sur site, et le serez toujours (il n'y a qu'UN badge d'entrée).
Aucune crainte à avoir que vous soyez plusieurs à vouloir pisser, les toilettes sont, pour le moment, à votre usage exclusif ! Sympa en cas de gastro.
En partant, vous remettez le badge à l'entrée, et quelqu'un d'autre peut l'utiliser.
Il est difficile de donner un exemple "physique", IRL au deadlock, ce sera voyant dans l'exemple :
Imaginons deux mutex indépendants, mA et mB.
Dans votre code (, qui sera thread1) vous acquérez mA. Une fois fait, vous acquérez mB. Vous ne cherchez à acquérir mB que si vous avez mA (c'est vous qui avez le badge de mA quand vous allez voir si le badge de mB est disponible)
Maintenant, un autre code (, qui sera thread2), lui, fait l'inverse. Il acquiert mB. Une fois fait, il cherche à acquérir mA. Donc, lui, dans sa logique, il a le badge mB quand il va voir si le badge de mA est disponible.
Donc imaginons une situation qui aboutit au deadlock :
Thread1, vous acquérez mA. Vous êtes le premier, donc le badge est dispo, vous le prenez. Puis on pause.
Thread2, il acquiert mB. Il est le premier, le badge de mB est dispo, il le prend. On pause. On vient d'entrer dans un deadlock
Thread1, vous voulez acquérir mB. Mais il est déjà pris par thread2.
Thread2, il veut mA, mais il est déjà pris par thread1.
Donc, ceci est un deadlock. Pour que Thread1 acquiert mB, il faudrait que thread2 le libère. Mais il ne le fera qu'après avoir acquis mA. mA qui est bloqué par thread1, qui attend mB. Débloquable par thread2, qui est en attente de mA ......
Spazi a très bien expliqué et le problème est en fait général, pas seulement lié aux threads, mutex mais aussi à toute ressource partagée.
L'idée, c'est de dire "ok, je suis le seul à accéder à un truc tant que je ne l'ai pas remis à la disposition de la communauté".
Et donc tu réserves A, je réserve B, là, tu veux réserver B et moi A. Cela fait un cycle, on est coincé.
Cela existe pour les fichiers, les bases de données, etc. Et sans doute même dans des trucs en dehors de l'informatique.
"Les injonctions contradictoires" en psychologie.
Pourrais-tu développer, afin que l'on puisse éventuellement apprécier la profondeur de ton intervention?
Ok merci beaucoup spazi et pm42 pour cette très bonne explication. Je comprends beaucoup mieux maintenant
En effet je pensais avoir lu que ça se correspondait mais cest sûrement une erreur.
