Discussion :

[Dliw0]

Bonjour,

J'ai un soucis de compr�hension quant-� l'usage des conditions de l'interface pthread.
� ce que j'ai compris, le fonctionnement est proche des s�maphores, sauf qu'il existe une fonction broadcast pour lib�rer l'ensemble des threads en attente.

J'essaie donc de mettre en �uvre l'algorithme suivant, mais cela ne fonctionne pas.
Voici en pseudo-code la fonction thread :

Code :

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

1
2
3
Attendre une condition (avec pthread_cond_wait)
Afficher un message
Se terminer

Et la fonction principale du programme :

Code :

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

1
2
3
4
Créer n threads devant exécuter la fonction ci-dessus
Envoyer un signal général informant que la condition est respectée (avec pthread_cond_broadcast)
Attendre la terminaison des n threads (avec pthread_join)
Se terminer

Mais voil� : le programme ne se d�roule pas comme pr�vu, je tombe dans un deadlock.

Je pensais que :
- Dans le cas o� un thread se met en attente de signal, il se d�bloque lorsqu'il le re�oit avec broadcast.
- Dans le cas o� le broadcast a lieu avant la mise en attente du thread, celui-ci ne se bloque pas.

Mais apparemment ce n'est pas le cas. Quelqu'un peut-il donc m'�clairer sur ce qui ne vas pas ?
Merci d'avance.


Si besoin voici l'impl�mentation C que j'utilise :

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
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
 
 
#define NB_THREADS 10
static pthread_cond_t cond = PTHREAD_COND_INITIALIZER ;
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER ;
 
 
void* bonjour (void* pdata) {
  pthread_cond_wait (&cond, &mutex) ;
  printf ("Message du thread %ld\n", (long) pdata) ;
  pthread_exit (NULL) ;
}
 
 
int main (int argc, char** argv) {
  long i ;
  pthread_t t [NB_THREADS] ;
 
  for (i = 0 ; i < NB_THREADS ; i++)
    pthread_create (&t [i], NULL, bonjour, (void*) i) ;
 
  pthread_cond_broadcast (&cond) ;
 
  for (i = 0 ; i < NB_THREADS ; i++)
    pthread_join (t [i], NULL) ;
 
  return 0 ;
}

[transgohan]

Je pensais que :
- Dans le cas o� un thread se met en attente de signal, il se d�bloque lorsqu'il le re�oit avec broadcast.
- Dans le cas o� le broadcast a lieu avant la mise en attente du thread, celui-ci ne se bloque pas.

1/ C'est le cas.
2/ Non il se bloque, le signal a �t� re�u avant qu'il se mette en attente. Il doit de nouveau recevoir le signal pour se d�bloquer.
Un signal est un one-shot, ce n'est pas une activation d'�tat.
Tu as l'explication ici : http://pubs.opengroup.org/onlinepubs...cond_wait.html

[Dliw0]

D'accord je vois merci.

J'en conclus que cette m�thode (les conditions) n'est pas la bonne pour r�soudre ce genre de probl�me.
Comme on ne peut pas avoir la garantie qu'un thread est en attente de condition avant de lui envoyer un signal, il me semble plus adapt� d'utiliser des s�maphores traditionnels ; � moins qu'il y est mieux ?

Et par curiosit�, dans quels cas pratiques fait-on usage des conditions ?

[transgohan]

Dans ton utilisation il semblerait en effet que les s�maphores soient mieux.
Pour la diff�rence d'utilisation je ne saurai dire, je n'ai encore jamais eu l'occasion d'utiliser des signaux (sauf au travers de l'utilisation de fifo).

Mais je pense (� confirmer) que les signaux sont plus rapides que l'utilisation de s�maphore.
Je travaille sur du code o� � certaines sections critiques les anciens dev ont utilis� des files(sans message, juste une adresse) � la place de s�maphore.

[Dliw0]

Parfait merci pour tes r�ponses je passe en r�solu