Bonjour,
Je viens de m'apercevoir que plusieurs mutex.lock() consécutifs (testé avec 10 lock consécutifs) ne sont pas bloquants au niveau des lock() suivants le premier alors qu'ils devraient.
sf::Mutex x;
for(int i=0; i != 10; ++i)
x.lock()
Ceci rend donc impossible le blocage d'un thread par lui-même pour être ensuite débloquer par un autre thread.
Dans le cas où les lock consécutifs seraient une erreur, le débogage devient un peu plus compliqué et certaines erreurs pourraient devenir très difficiles à trouver.
Est-ce une erreur ou est-ce voulu?
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.
J'ai un thread qui se charge de la réception de paquet :
//thread producteur.
//création des threads consommateurs
while(running)
{
//je construit un TcpListener et un SocketSelector
while(running && ! bloque)
{
//reception d'un paquet
//si nécessaire ajoute le paquet à une file de paquet. Le paquet sera alors traité par un ensemble de thread consommateurs.
}
//destruction du TcpListener et tu SocketSelector
if(bloque)
//on bloque le thread jusqu'à ce qu'on décide de rouvrir le serveur aux clients
}
//destruction des threads consommateurs
Ainsi si le serveur reçoit plusieurs instructions (reçu par un autre thread avec un listener qui écoute sur un autre port) selon lesquelles il doit bloquer (ou débloquer) le thread producteur, on peut les traiter sans se soucier de l'état du thread producteur.