Discussion :

[borisd]

Un mutex, c'est juste un objet tout seul qui possède un nom, et qui ne peut être possédé que par un thread. C'est tout ce que c'est. Après, on peut l'attendre, le prendre, le rendre... Rien de plus, et je pense que ça permet justempent de bien s'adapter à ton cas particulier (il s'est pas brossé les dents mon algo ?)

[jobherzt]

ok, ma question n'etait pas clair, j'essaie de preciser :

j'ai une variable globale qui est un objet "mutex"
dans chaque thread, j'ai une variable locale qui est de type "lock", qui est associé a l'objet mutex sus defini

quand je touche a qqchose qui doit etre protégé, je bloque mon objet lock, puis je le debloque ensuite..

donc je dois me planter qq part, car mon mutex n'est pas explicitement associé a ma pile. pourtant, ca marche :-)

[jobherzt]

voici un exemple simple dont je me suis inspiré :

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
 
#include <boost/thread/thread.hpp>
#include <iostream>
 
int count = 0;
boost::mutex mutex;
 
void increment_count()
{
   boost::mutex::scoped_lock lock(mutex);
   std::cout << "count = " << ++count << std::endl;
}
 
int main(int argc, char* argv[])
{
   boost::thread_group threads;
   for (int i = 0; i < 10; ++i)
      threads.create_thread(&increment_count);
   threads.join_all();
}

ici, c'est bien evidemment count qui doit etreprotégé, mais a aucun moment on ne dit "le mutex est la pour proteger count", on bloque un point c'est tout...

[borisd]

Selon l'utilisation que tu en fais, c'est toi qui intrinsèquement le lies à une ressource (en bloquant le mutex dès que tu accède à la ressource). Donc ça marche, bien entendu!
Mais peut-être qu'avec la librairie que tu utilises il est possible de le faire explicitement, je ne la connais pas, mais on n'a pas forcément besoin.
Utiliser des outils génériques est une bonne chose pour éviter des bugs, mais je pense qu'il ne faut pas tomber dans un moule de cas d'utilisation prédéfinis si on veut faire de l'optimisation...

[jobherzt]

oui, en fait, je viens de comprendre le degre de debilité de ma question... passons, passons... désolé !!

[borisd]

C'est la chaleur, on est tous un peu en surchauffe...

[Eusebe]

Moi je pense que deux mutex sont nécessaires :
- un mutex pour gérer l'attente de remplissage de la pile (si elle est vide et que d'autres threads travaillent encore) ;
- un mutex pour protéger l'accès à la pile.

Cela éviterait de bloquer un thread qui veut empiler quelque chose parce qu'un autre thread bloque la pile parce qu'elle est vide

L'algorithme serait le suivant :

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
Prendre le mutex d'attente
    Tant que l'on a pas de travail et que des thread bossent
        Prendre le mutex de la pile
            si la pile n'est pas vide
                dépiler
                incrémenter NT
            fin du si
        Liberér le mutex de la pile
        Si on a pas de travail, attendre x ms
     Fin Tant que
Libérer le mutex d'attente
(travail...)
Prendre le mutex de la pile
    empiler (si besoin)
    décrémenter NT
Libérer le mutex de la pile

Comme ça, on a un seul thread qui regarde si la pile est vide ou pas. L'attente de x ms si ce thread n'a pas de travail est là pour éviter qu'il bouffe trop de temps cpu à faire sa boucle...

[jobherzt]

oui, j'avais pense a un mutex en plus, en gros :

pour ecrire dans la pile -> prendre le mutex de la pile

pour lire la pile -> prendre le mutex de la pile ET un mutex qui est bloqué quand la pile est vide.

mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...

[Eusebe]

mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...

Là, je ne te suis encore plus du tout

Est-ce que le pseudo-algorithme que j'ai proposé ne te conviendrais pas ?

[borisd]

mais effectivement, dans ce cas, il semblerait qu'il faille qu'un thread puisse debloquer un mutex qu'un autre avait bloqué...

en effet! Ca ne doit pas être possible! La solution d'Eusebe parait pas mal du tout (reste à paramétrer le temps d'attente pour ne pas attendre trop longtemps en ne consommant pas trop de cpu).

[borisd]

Et en utilisant un sémaphore au lieu d'un mutex pour l'attente ?
Les sémaphores peuvent être incrémentés ou décrémentés par n'importe quel thread. On l'incrémente quand on met un élément dans la pile, quand on enlève on l'attend au besoin et on le décrémente . Ca paraît mieux que la solution d'Eusebe, il n'y a pas d'attente.
(Les sémaphores, c'est comme les mutex, mais pas unitaires : il n'est plus dispo quand le nombre qui lui correspond est nul, et il est dispo dès que ce nombre est strictement positif, sans limite supérieure (enfin, théoriquement). On peut lui piquer une unité s'il en a, sinon on doit attendre, et on peut lui en ajouter une, et ce à partir de n'importe quel thread)

[jobherzt]

ca serait pas mal, je vais regarder !!

si, Eusebe, ca me semble pas mal, mais ca bloque l'acces a la pile pendant X secondes, ca peut poser probleme, non ?? je vais reflechir a tout ca a tete reposé..

et n'oublions pas que pour l'instant ca marche, meme si ce coup de la boucle qui tourne en rond n'est peut etre pas terrible.. je vais deja faire des tests pour voir si je neperds pas en perf !

[Eusebe]

si, Eusebe, ca me semble pas mal, mais ca bloque l'acces a la pile pendant X secondes, ca peut poser probleme, non ?? je vais reflechir a tout ca a tete reposé..

Non, ça ne bloque pas l'accès à la pile pendant x secondes. La pile est libre la plupart du temps, ça évite juste que la boucle tourne trop en rond.

Mais en effet, comme le propose borisd, un sémaphore pourrait peut-être t'aider (à étudier )

[jobherzt]

comme il faut bien que la fonction rechercher donne des resultats, je remonte ce post pour dire que la librairie boost_thread offre une classe condition qui facilite le schmilblick.

le principe : je declare un objet estLibre de type classe condition en global.

si la pile est vide, j'ai une methode :

Code :

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

1
2
 
estLibre.wait(verrou)

ou verrou est un verrou sur un mutex. cette fonction libere le mutex (il fallait qu'il soit verrouillé) et met le thread en pause. ensuite, des que quelqu'un met un truc dans la pile, il envoie un :

Code :

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

1
2
 
estLibre.notify_all()

qui, comme son nom l'indique, signale aux autres threads qu'il y a de nouveau du taf .. en gros, tous les threads qui etaient en wait se remettent en route, et l'un d'entre eux prend directement le verrou, et les autres attendent tout a fait normalement que le verrou se libere pour agir.

ca me force quand meme a faire quelque test un peu lourd, mais c'est une solution assez "propre" !!

encore merci a tous pour vos precieux conseils !

du coup, ca m'oblige quand meme a rajouter des test un peu redondants,

[uriotcea]

bonjour,

Si tu es noyé dans la complexité des threads as-tu songé à regarder MPI.
Ca permet de paralleliser une application de maniere simple. C'est destiné aux calculs scientifique et c'est completement free

Didier

[jobherzt]

je decouvre en effet la joie du debuggage multi thread, et la merveilleuse part d'aleatoire que ca introduit...

sauf erreur, MPI sert a echanger des messages entre plusieurs sous processus, donc il faut deja avoir paralleliser le schmilblick pour l'utiliser, et ca s'applique surtout dans un contexte de cluster, pour l'instant je n'ai "qu'un" bi processeur a ma disposition :-)

[Matthieu Brucher]

sauf erreur, MPI sert a echanger des messages entre plusieurs sous processus, donc il faut deja avoir paralleliser le schmilblick pour l'utiliser, et ca s'applique surtout dans un contexte de cluster, pour l'instant je n'ai "qu'un" bi processeur a ma disposition :-)

Eh oui, c'est plus cluster parce que communication par message et non par mémoire partagée, mais même avec un bi-proc, il n'y a pas de souci, tu parallélises et tu fais un mpirun avec un nombre de threads supérieurs à 1, et c'est bon, quand tu passeras à un cluster, il y aura moins de bugs.

[uriotcea]

cluster ou PC multiprocesseur, c'est totalement transparent pour MPI. En effet il faut juste lui indiquer le nombre de process et leur repartition. J'ai essayé il y a quelque temps sur un bi-pro: Gain=2

[jobherzt]

par curiosité, quel serait l'avantage pour moi, par rapport a du multithread ? en ajoutant qu'il ya des données partagées entre les threads qui doivent etre accessible en temps reels...

a terme, si je passe sur un cluster, ce sera avec de la memoire partagée et un systeme type Mosix pour repartir les threads de maniere transparente sur les nodes du cluster. pensez vous que j'ai malgré tout interet a utiliser MPI ?

[uriotcea]

J'y voyais seulement une facilté à metre en oeuvre. Maintenant j'avoue ne pas assez connaitre ce produit pour dire comment il gere la memoire partagé
désolé