Disons que j'ai une fonction qui fait un mutex.lock qui appelait une fonction qui elle-même appelait une fonction qui faisait aussi un mutex.lock.
Or comme je n'avais pas de deadlock, trouver l'erreur a été beaucoup plus compliqué.
Sachant que l'erreur pouvait ne pas se manifester à chaque coup...
Sinon pour tes cas très particulier, il y a la réunion :
//thread 1
m.lock();
while(1)
{
n.unlock();
m.lock(); //attente du thread 2
}
//thread2
n.lock();
while(1)
{
m.unlock();
n.lock(); //attente du thread1
}
blocage d'un thread :
m.lock();
while(running)
{
//construction d'un élément quelconque
while(running && ! bloque)
{
//utilisation de l'élément
}
//destruction de l'objet
if(bloque)
m.lock();
}
//thread2
bloque = true; //blocage
//.....
bloque = false;
m.unlock(); //déblocage
Je ne vois pas l'intérêt de ne pas bloquer lors de lock consécutifs.
Si les lock consécutifs sont dû à une erreur, alors on ne résout pas l'erreur, on ne fait que la cacher.
C'est un peu comme un :
try
{
}
catch(..)
{
//erreur ;-)
}
On empêche juste l'application de planter sur le coup mais rien ne l'empêche de planter plus tard justement à cause de cette erreur.
