pthread et mutex

**Nico65** · 12/01/2005, 16h21

bonjour

j'ai un petit souci avec mon mutex pthread qui se comporte pas comme j'aimerais

il me semblait que d'une certaine maniere pthread faisait une queue FIFO de tous les thread qui faisaient lock() sur un mutex deja locke, et qu'il les reveillait dans l'ordre dans lequels ils sont appelle lock(), et apparement c'est pas forcement le cas. Sur 2 machines j'ai 2 comportement different, ce qui me pose probleme c'est que sur l'une :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
while (true) {
   mutex.lock();
   ...
   mutex.unlock();
}

ne rend jamais la main a d'autres threads qui auraient appelle mutex.lock()

aurais-je mal initialise mon mutex ?
je l'initialise commee suit :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
pthread_mutex_t* lMutex = new pthread_mutex_t;
if(::pthread_mutex_init(lMutex, 0))
   throw Exception(eOtherError, "Mutex::Mutex() can't create!");

**Higestromm** · 12/01/2005, 16h27

je ne suis pas sur mais je crois que tu confond mutex et s�maphore...
Pour recuperer un mutex c'est un peu du hazard
Pour recuperer un s�maphore il y a un sisteme de liste

Donc ton comportement ne me parais pas plus �trange que ca vu que ta boucle ne fait rien d'autre... mais bon ... je peux me tromper

**Nico65** · 12/01/2005, 16h37

Envoy� par Higestromm

Pour recuperer un mutex c'est un peu du hazard

sans dec

Envoy� par Higestromm

Pour recuperer un s�maphore il y a un sisteme de liste

un semaphore initialise a 1 donc... j'ai essaye et j'ai malheureusement un resultat similaire, faut que je regarde dans l'implementation de ma semaphore

Envoy� par Higestromm

Donc ton comportement ne me parais pas plus �trange que ca vu que ta boucle ne fait rien d'autre... mais bon ... je peux me tromper

je sais pas si c'est etrange, mais je dit que c'est du delire, car imagine une autre fonction similaire apellee dans un autre thread... serait en permanence bloquee

**Jan Rendek** · 12/01/2005, 17h05

Il n'y a aucune gestion de liste d'acc�s avec un mutex. Une fois le verrou lib�r�, les threads sont remis en concurrence pour l'acc�s au verrou. L'allocation d�pend de l'ordonnanceur natif de l'OS.
Le code que tu montres peut donc amener une situation de famine.
Les mutex sont utiliser pour garantir l'acc�s � une ressource en situation d'exclusion mutuelle.

Pour synchroniser un ensemble de t�ches, il faut utiliser d'autre type de primitive de synchronisation comme les semaphores, ou les 'variables conditions'

**Gandalf** · 12/01/2005, 17h52

d�j� avec un sleep(0) derriere le unlock() cela devrait mieux marcher...

Mais effectivement il n'y a aucune gestion de liste pour l'acces � un mutex...

le sleep(0) permet de redonner la main a un autre thread/process au niveau de l'ordonnacement...

**Jan Rendek** · 12/01/2005, 18h08

La synchronisation de t�che, c'est en g�n�ral quelquechose qui se plannifie. Il est impossible de se baser sur de la bidouille. Peut-�tre qu'avec un sleep(), un printf, ou je ne sais quoi �a peut ponctuellement emp�cher la famine, mais cela ne r�soud rien.
Le m�me code avec un compilo diff�rent, ou une plate-forme diff�rente ou une charge sur la machine diff�rente produira le m�me genre de probl�me.
De plus, la solution ici est simple. Utiliser un s�maphore.

**Nico65** · 12/01/2005, 18h34

Envoy� par VoidSeer

Utiliser un s�maphore.

ah mais je te crois sur parole 8)
je pensais qu'un mutex et qu'une semaphore de 1 etait la meme chose, voila je me coucherais moins bete ce soir

probleme : mon implementation n'est apparement pas plateforme-independante car meme avec une semaphore de 1 le probleme persiste, ca delire profond et je vais changer d'implementation (et merdeuuuu). peut etre une bonne raison de passer a quelque chose de plus serieux. vous me conseillez quoi, boost ?

merci pour le sleep(0), ya de l'idee mais bon

**Jan Rendek** · 12/01/2005, 18h44

Normalement avec les pthread sont compatible avec toute les plate-formes Unix. Je trouve le probl�me �trange...
Dans l'absolu, l'utilisation d'une biblioth�que de synchro risque de ne pas changer grand-chose, vu que beaucoup encapsulent les pthreads.
On peut en voir un peu plus (pas trop hein...) du code ? Y'a peut-�tre un probl�me tout pipi ?
Ou mieux, avoir une id�e du pb � r�soude ?

**Nico65** · 12/01/2005, 19h31

j'utilise les classes dispo ici : http://manitou.gel.ulaval.ca/~parizeau/PACC/
je sais que c'est pas standard mais c'est simple et puis c'est pas une usine a gaz. Ca encapsule les pthread

si je decommente le sleep(0.01) ca marche comme espere mais...

sinon le thread2 n'a jamais acces

j'ai un peu trace le probleme dans le code de semaphore, lorsque la condition fait signal l'autre ne se reveille pas tout de suite (pourquoi ?) et le temps qu'elle se reveille, le thread 1 est deja retourne dans le code

en attendant mieux je vais mettre ce sleep(0.01) dans le code de post()... pas que ca a faire moi

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
 
PACC::Threading::Semaphore semaphore(1);
 
class Test : public PACC::Threading::Thread {
  char c;
  int w, w2;
public:
  Test(char c_, int w_, int w2_) : c(c_), w(w_), w2(w2_) {}
protected:
  void main() {
    sleep(w);
    while (true) {
      cout << c << " wait" << endl;
      semaphore.wait();
      cout << c << " got access" << endl;
      sleep(w2);
      cout << c << " post" << endl;
      semaphore.post();
      sleep(0.01);
    }
  }
};
 
 
 
int main(int argc, char *argv[])
{
  Test t1('1', 0, 2);
  Test t2('2', 1, 2);
 
  t1.run(); t2.run();
  t1.wait(); t2.wait();
}

**JolyLoic** · 12/01/2005, 21h07

boost::thread m'avais l'air pas mal, pas tellement dans la fa�on somme toute classique dont il traite la concurrence, mais surtout dans la fa�on dont il est exception safe.

**Jan Rendek** · 13/01/2005, 08h40

Ce que tu as, c'est un vrai pb de synchronisation. Avec ton code, la t�che 1 peut boucler � l'infini

Une solution classique � ce probl�me est d'utiliser 2 s�maphores de synchonisation (initialis�s � 0)
Soit sem1, sem2 rattach�s respectivement � la t�che 1 et t�che 2.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
    Tâche 1                                 Tâche 2
 
  sem1.wait()                    
        |                                    sem1.post()
        |  (section critique)        sem2.wait()
        |
  sem2.post()

**Nico65** · 13/01/2005, 10h20

alors d�sol� l� je ne te suis pas du tout... dans ton exemple la t�che 2 va "autoriser" la t�che 1 a fonctionner en section critique, et inversement

mais je n'ai jamais dit que la fonction de la t�che 2 ALLAIT �tre appell�e, j'ai dit qu'elle POUVAIT l'�tre (ou pas) et dans ton cas la t�che 1 attendrait, ca va pas

en pratique j'ai plus de 2 fonction (une qui tourne en boucle et d'autres normales type mutex)... et si aucune n'est "en attente" je veux qu'elle continue � tourner en boucle

tu ne semble pas valider mon id�e de semaphore de 1 (ci dessous)... pourquoi ? probl�me identique � mutex ?

====>>> est ce que tu comprend mon id�e de "queue" de processus en attente ??? est-ce demander la lune ???!!!! je suis parfaitement OK avec ton semaphore de 0 mais il ne r�pond pas � mon probl�me particulier

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
sem = semaphore(1)
tâche 1 : boucle {sem.wait(); ... ; sem.post();} fin de boucle
tâche 2 : boucle {sem.wait(); ... ; sem.post();} fin de boucle

**Jan Rendek** · 13/01/2005, 20h20

Effectivement la solution que avec 2 semaphore permet de faire fonctionner alternativement 2 t�che. Cela ne r�pond pas directement � ton probl�me.

Le pb avec ton code c'est qu'il se peut que ta t�che 2 ne soit jamais �lue. A la r�flexion, je ne suis pas tr�s s�r qu'il y est un m�chanisme de liste d'attente ordonn�e sur les s�maphores de la norme posix. Si je me rappelle bien, ils sont bas� sur les 'condition variables', y'a donc de grande chance qu'une fois le jeton lib�r�, il y est encore un pb de concurrence.

J'ai une solution un peu ad hoc, que je n'ai pas le temps de tester, ni m�me de vraiment regarder de pr�s, alors, ne tirez pas sur le pianiste.

L'id�e est de v�rifier � chaque it�ration de la t�che principale, si aucune t�che n'est en attente. Si c'est le cas, il faut les synchroniser puisque la t�che 2 doit �tre la seule � s'executer. La m�thode doit pouvoir se g�n�raliser facilement � N t�ches.

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
 
sem_1 : sémaphore de synchro de la tâche principale
sem_2 : sémaphore de la tâche ponctuelle 
mutex : garde d'accès aux données partagée entre les 2 tâches
is_waiting : booléen valant vrai si la tâche 2 cherche à intervenir (initialisé à 0)
 
Tâche principale     
------------------
loop                        
  mutex.lock()   
  if (is_waiting)
    mutex_unlock             
    sem2.post()  /* Active la tâche en attente */
    sem1.wait()  /* Se met en attente de la fin de T2 */
 
  else
    mutex.unlock()
  fi
    /* Vit sa vie */
  end loop
 
 
Tâche 2
---------
  mutex.lock()
  is_waiting = true
  mutex.unlock()
 
  sem2.wait()  /* Attend la fin d'execution de l'itération de T1 */
 
  /* Vis sa vie en exclusion avec T1 */
 
  // Clean
  mutex.lock()
  is_waiting = false
  mutex.unlock()		
 
  sem1.post() /* Réveille T1
  die.

On peut g�n�raliser ceci � N t�che, en utilisant, en plus du bool�en, un vecteur dans lequel on empile les r�f�rences sur les s�maphores priv�s des N t�ches en attente, que l'on lib�re 1 par 1.

Une fois encore, c'est un code pondu en 5 min, donc � prendre avec des pincettes.

**Higestromm** · 13/01/2005, 20h58

Un peu hors sujet mais ca m'interesse beaucoup.

Est ce qu'il existe un equivalent des sections critiques windows en standard dans le c++ ou bien fonctionnant sous linux ?

**Nico65** · 13/01/2005, 21h05

merci pour ton algo je regarderais ca

j'ai compris le probleme (c'est d�ja bien) de mon algo d'au dessus... je reflechis � une solution generique style queue fifo de semaphores et je te/vous tient au jus

**Nico65** · 13/01/2005, 21h10

en standard dans le c++

ya rien en standard, c'est OS/lib d�pendant. Mais les pthread sont portables

sur Windows ya aussi l'api Win32 g�re ca - mais pour moi Win32 c'est un charabiat de langue morte

-

**SKZ81** · 14/01/2005, 02h37

Ha bon, POSIX n'est pas un standard ?

Le soucis (que tu semble avoir compris) est que la prabalit� que le scheduler passe la main � un autre thread entre la fin et le d�but du while() (le unlock est suit suivit par un JUMP, un test et un lock, puis la section critrique, puis re*, etc...) est vraiment tr�s faible. Suffisemment, visiblement pour que �a n'arrive jamais dans un test "grandeur nature"...

D'o� l'id�e du sleep() qui force � passer la main, ne parra�t pas du tout une bonne id�e.

En ce qui concerne la FIFO des thread, c'est vrai � condition d'utiliser cette politique. Pour info elle impl�mente FFP (Fixed Priority Premptive), contrairement � Round-Robin (et c'est uniquement dans ce cas qu'il est appropri� de parler de "jeton"... Bon j'ai quand m�me compris le post qui utilise ce terme, and that's the point). Si tout test thread ont la m�me priorit�, ceci dis, �a revient au m�me...

C'est pas parceque les threads sont organis� en FIFO (dans l'ordonanceur) qu'il chope le mutex en FIFO. Donc ce qu'il faut c'est apr�s le unlock() c'est un genre de "yield()", c'est � dire une fonction qui dis � l'ordonnanceur de passer la main � un autre thread, qui verouillera le mutex, etc...

Au pire tu peux toujours impl�menter une liste d'abonnement qui impl�mentera la FIFO sur le mutex... La tu sera s�r du comportement... 8)

**Nico65** · 14/01/2005, 12h32

ok j'ai pondu quelque chose (je pr�cise que j'ai taill� ca a la serpe et au burrin)

implementation :

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
 
class FifoMutex {
    Mutex mutex;
    deque<Semaphore *> freeSem;
    deque<Semaphore *> waitingSem;
    Semaphore * computingSem;
 
	void init(int i) {
	    computingSem = NULL;
		for (int j=0; j<i; j++) freeSem.push_back(new Semaphore(0));
	}
 
public:
	FifoMutex() {init(32);}
 	FifoMutex(int i) {init(i);}
 
	void lock() {
	    mutex.lock();
		Semaphore * sem;
		if (freeSem.empty())
  			sem = new Semaphore(0);
		else {
  			sem = freeSem.front();
  			freeSem.pop_front();
		}
		if (computingSem == NULL)
			computingSem = sem;
		else {
			waitingSem.push_back(sem);
	   	    mutex.unlock();
			sem->wait();
			return;
		}		
   	    mutex.unlock();
	}
 
	void unlock() {
	    mutex.lock();
		if (waitingSem.empty())
			computingSem = NULL;
		else {
		    computingSem = waitingSem.front();
		    waitingSem.pop_front();
		    computingSem->post();
		}    
   	    mutex.unlock();
	}
};

test :

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
62
63
64
65
66
 
Mutex mutex;
FifoMutex fifoMutex;
 
class MutexTest : public PACC::Threading::Thread {
  int c;
  float w, w2;
public:
  MutexTest(int c_, float w_, float w2_) : c(c_), w(w_), w2(w2_) {}
protected:
  void main() {
    sleep(w);
    mutex.lock();
    cout << c << " got access" << endl;
    sleep(w2);
    mutex.unlock();
  }
};
 
class FifoMutexTest : public PACC::Threading::Thread {
  int c;
  float w, w2;
public:
  FifoMutexTest(int c_, float w_, float w2_) : c(c_), w(w_), w2(w2_) {}
protected:
  void main() {
    sleep(w);
    fifoMutex.lock();
    cout << c << " got access" << endl;
    sleep(w2);
    fifoMutex.unlock();
  }
};
 
 
 
int main(int argc, char *argv[])
{
  int nb = 10;
  float sleep = 0.4;
  MutexTest* mutextest[nb];
  FifoMutexTest* fifotest[nb];  
 
  cout << "according to fifo rule, should be 0 -> 10" << endl;
  cout << "---------- MUTEX TEST ---------" << endl;
  for (int i=0; i<nb; i++) {
   	mutextest[i] = new MutexTest(i, i * 0.02, sleep);
   	mutextest[i]->run();
  }
  for (int i=0; i<nb; i++) {
	mutextest[i]->wait();
	delete mutextest[i];
  }
 
  cout << "---------- FIFO-MUTEX TEST ---------" << endl;  
  for (int i=0; i<nb; i++) {
   	fifotest[i] = new FifoMutexTest(i, i * 0.02, sleep);
   	fifotest[i]->run();
  }
  for (int i=0; i<nb; i++) {
	fifotest[i]->wait();
	delete fifotest[i];
  }
 
	system("pause");
}

resultat sur ma machine qui posait probleme :

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
 
according to fifo rule, should be 0 -> 10
---------- MUTEX TEST ---------
0 got access
9 got access
8 got access
7 got access
6 got access
5 got access
4 got access
3 got access
2 got access
1 got access
---------- FIFO-MUTEX TEST ---------
0 got access
1 got access
2 got access
3 got access
4 got access
5 got access
6 got access
7 got access
8 got access
9 got access

ya du mieux

**Jan Rendek** · 14/01/2005, 14h39

Arf, c'est qu'� tous on est p't'�tre pas si mauvais.

Allez, classe l'affaire va !

**SKZ81** · 15/01/2005, 04h53

Bon la flemme de lire tout �a � 5 heure moins 10... Honte � moi

Mais j'aime bien :

Envoy� par Nico65

ok j'ai pondu quelque chose (je pr�cise que j'ai taill� ca a la serpe et au burrin)

Un de mes amis celtique ?

Ferais-tu parti des "amis de Merlin", ceux qui se r�unissent p�riodiquement dans [ce qui reste de] Broc�liande ? UN BRETON QUOI !!?

Aller, Breizh A Tao, c'est pas a toi, mais TOUS que je le dis ! Vive Engann !!!

(Je d�lire, bretonnant mais pas cingl� je suis...)

pthread et mutex

C++

Vue hybride

Discussions similaires

Partager

Partager