Discussion :

[Sleev]

Bonjour à tous,

Je rencontre quelques soucis avec l'utilisation de la librarie OpenThreads (composant d'OpenSceneGraph) et la documentation étant très peu fournie, je me demandais si quelqu'un ici pouvait m'aider.

Le problème est tout simple : le "lock" que je fais sur un mutex n'est pas bloquant et toujours valide. Je n'arrive pas à comprendre pourquoi.

Par exemple le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
OpenThreads::Mutex mutex;
 
mutex.lock(); // Là tout devrait fonctionner
mutex.lock(); // Là je devrais être bloqué ou l'instruction devrait échouer
int a = 3;    // Bizarrement cette instruction est éxécutée

J'ai utilisé un peu pthread auparavant et il me semblait que lorsqu'on faisait un lock sur un mutex, l'instruction était bloquante, c'est bien ça ?

[Médinoc]

Sous certains systèmes, les mutexes autorisent le verrouillage récursif au sein d'un même thread, pour éviter qu'un thread se mette en "étreinte fatale" à lui tout seul.

[Sleev]

Mais dans ce cas, comment tester que les mutexes sont verrouillés ? Ici les instructions me retournent toutes deux zéro.

Ce n'est qu'en utilisant des conditions que j'arrive à bloquer le thread en attente du mutex...

[Médinoc]

Mais dans ce cas, pourquoi tester que les mutexes sont verrouillés? Le thread qui a verrouillé un mutex le sait, et il n'a qu'à le mémoriser dans une variable locale.
Les autres threads le sauront quand ils essaieront à leur tour d'acquérir le mutex, vu que eux bloqueront ou échoueront (normalement, tu dois aussi avoir une version non-bloquante de la fonction de verrouillage, du genre trylock() ou une version avec timeout de lock()...)

[Arzar]

Bonjour

Ce n'est qu'en utilisant des conditions que j'arrive à bloquer le thread en attente du mutex...

Je ne comprends pas cette phrase, c'est exactement le rôle du mutex lorsqu'on appelle lock() que de bloquer le thread d'où a été fait l'appel jusqu'à ce que le mutex se libère.

[Sleev]

Justement, mon problème est que l'appel à lock() ne bloque rien du tout. Que ce soit dans un unique thread ou dans deux différents.

Mais je m'explique. En fait je souhaite faire un programme ou deux threads écrivent dans la console l'un après l'autre. Sachant qu'un thread ne peux pas écrire deux fois de suite. Voila mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#include <cstdlib>
#include <ctime>
#include <iostream>
#include <OpenThreads/Condition>
#include <OpenThreads/Mutex>
#include <OpenThreads/ReadWriteMutex>
#include <OpenThreads/Thread>
#include <string>
 
class MessageThread : public OpenThreads::Thread
{
	public:
		MessageThread(const std::string &message, OpenThreads::Mutex *mutex1, OpenThreads::Mutex *mutex2) : OpenThreads::Thread()
		{
			mMessage = message;
			mMutex1 = mutex1;
			mMutex2 = mutex2;
		}
 
		virtual ~MessageThread()
		{
			this->cancel();
		}
 
		virtual void run()
		{
			if (mMutex1 == NULL || mMutex2 == NULL)
				return;
 
			while (true)
			{
				mMutex1->lock();
				std::cout << mMessage << std::endl;
				OpenThreads::Thread::microSleep((rand() % 4) * 500000);
				mMutex2->unlock();
			}
		}
 
	protected:
		std::string mMessage;
		OpenThreads::Mutex *mMutex1;
		OpenThreads::Mutex *mMutex2;
};
 
int main(int argc, char **argv)
{
	srand(time(NULL));
 
	OpenThreads::Mutex m1;
	OpenThreads::Mutex m2;
 
	MessageThread thread("Hello", &m1, &m2);
	MessageThread thread2("World", &m2, &m1);
 
	thread.start();
	thread2.start();
 
	OpenThreads::Thread::microSleep(100000000);
 
	return 0;
}

Cela devrait marcher non ? Sauf qu'au final, l'appel à lock() produit le même effet qu'un trylock() et mes deux threads écrivent un peu quand ils veulent dans la console...

[Médinoc]

C'est normal, vu ce que j'ai dit à propos des locks récursifs et le fait que tes deux threads utilisent des mutexes différents.

Tu devrais utiliser autre chose à la place, genre des sémaphores ou des événements.

[Sleev]

Effectivement, je viens de tester avec un même mutex pour des threads différents, le lock() fonctionne. C'est donc bien que le thread ne peut pas s'auto-bloquer...

Merci de ton aide, j'aurais mis du temps à comprendre mon problème sans cela !