thread, mutex, etc

Bonjour à tous,

Pour une application, j'utilise une implémentation existante des threads : OpenThreads.
le systeme de gestion des priorité de calcul, de maniere à ce que le programme ne fige pas en attendant la fin du thread, marche tres bien.
A présent je cherche à synchroniser ces threads.

Ce que j'ai sous la main est ceci : http://www.openscenegraph.org/projec...reads?rev=5495

les Mutex, et les Conditions semblent appropriés pour mettre en attente les threads et les relacher ensuite... mais je ne vois pas comment gerer tout ce là à savoir : où et comment utiliser les mutex/conditions pour interrompre les threads, connaitre leur état... etc..

Merci.

Pas très descriptif tout ça, pour un mini cours sur les threads:

- les mutexs sont généralement utilisés pour protéger une ressource partagée (ils permettent aussi d'implémenter à peu près tout, mais pour le reste autant utiliser un concept de plus haut niveau)

- les mutexs read/write c'est pareil mais quand on a beaucoup de threads qui lisent une donnée et peu qui vont écrire dedans.

- les variables de condition servent à faire bloquer un thread jusqu'à ce qu'une "condition" devienne vraie suite à l'intervention d'un autre thread

- les barrières servent à fixer un point de rendez-vous. Par exemple, imaginons que nous lançons X threads qui s'occupent chacun d'une Xième partie d'un calcul, mais nous avons besoin que le calcul en entier soit effectué avant de passer à la suite. Typiquement on utilisera une barrière sur laquelle vont bloquer tous les threads, quand le dernier thread aura fini ils seront tous débloqués.

les mutex seraient alors dediés à ce que je veux faire.

j'ai une pile partagée, que les threads remplissent tous en meme temps.

arrivé un point je vide cette pile, et donc je cherche à mettre en attente les threads à ce moment là, pour ne pas vider et remplir en meme temps cette meme pile.

les mutex sont ils dépendant d'un thread ? d'aucun ?

Si je fait un bete nouveau mutex suivit d'un lock() rien ne se passe...

Les "Barrier" ne peuvent-elles pas aider (si tu connais le nombre de thread qui devront êtres synchronisés) ?

Bonjour,

J'imagine qu'il existe déja un mutex pour le remplissage de ta pile pour eviter le remplissage simultané.

Dans ce cas, s'il y il a un unique thread chargé de vider la pile, il suffit qu'il verrouille le mutex de remplissage, puis traite la pile et enfin relâche le verrou.

Heuu alors en fait :

Pour le moment ma pile n'est pas encore implémentée dans les threads mais en effet, le remplissage devra se faire de maniere sychronisée sur tous les threads.

le nombre de thread varie au fur et à mesure de l'execution, mais je peux tabler sur une moyenne de 150 en parallele.

J'ai testé les barier, mais le seul résultat que j'ai eu (et normal) c'est qu'au moment om je met en place la barrier, le programme fige completement, sachant que la librarie principale est basé sur du multi-thread... je ne peux donc pas poser une barriere, car je dois pouvoir arreter seulement certains threads mais pas tous. Ensuite, ce qui est plus pénible, c'est que si je relase() ma bariere, le programme reste figé pour autant...

Je cherche donc à utiliser dans un 1er temps les mutex, ou indirectement via les scopedlock... mais si je met un mutex et dis mutex.lock(), rien ne se passe et tout roule que si de rien n'était...

la pile se videra de maniere synchronisée avec tous les thread créés, donc un nombre variable autre des 150... je dois donc pouvoir les stopper à ce moment là pour les faire repprendre ensuite...

l'idéal serait de modifier ma pile pour qu'elle gere elle meme la mise en attente des threads le temps du remplissage et du vidage, mais là je suis novice en thread en C++ et je ne sais pas dans quelle direction aller...

merci


Edit : d'une maniere plus simple, où et comment puis je utiliser les mutex ou autre ?

Citation:

---

Envoyé par Ange_blond

je suis novice en thread en C++ et je ne sais pas dans quelle direction aller...

---

Non, tu es novice en threads tout court. La différence c'est que les threads, mutex, barrières,... ça fonctionne partout pareil, seules les apis changent. Pourquoi je le dis? Parce que à ma connaissance il n'y a aucun méthode de test fiable pour tester un programme multi-thread. Le seul moyen est de s'assurer que nos algos sont théoriquement bons, si ils ne le sont pas ça fait un dead-lock, donc un programme qui ne fonctionne pas, donc un programme inutile. J'en conclus donc qu'il faut avoir une bonne connaissance de la théorie.

Désolé mais si tu t'étonne que rien ne se passe si tu fais un lock() sur un mutex il faut d'abord aller potasser un peu, on va pas te faire un cours de threads dans un forum alors qu'on en trouve un peu partout...

he bien justement, des cours sur les thread, concernant les mutex & Cie j'en ai pas trouvé... donc si tu as des bonnes références je suis preneur :D

merci.

En y regardant d'un peu plus près, il apparait qu'il n'y en a pas de généraliste sur developpez (rhooo, la honte). Mais en cherchant deux secondes sur google celui la a l'air pas mal : http://perso.numericable.fr/~pdeiber...ssus-leger.pdf .

Merci beaucoup

je lirai ça à tête reposée ce soir.

Salut,

Citation:

---

Envoyé par zais_ethael

Parce que à ma connaissance il n'y a aucun méthode de test fiable pour tester un programme multi-thread. Le seul moyen est de s'assurer que nos algos sont théoriquement bons, si ils ne le sont pas ça fait un dead-lock, donc un programme qui ne fonctionne pas, donc un programme inutile. J'en conclus donc qu'il faut avoir une bonne connaissance de la théorie.

---

Juste pour préciser qu'il y a des patterns (et des idiomes) de programmation concurrente visant à minimiser les problèmes potentiels, le plus simple pour éviter que quelque chose se produise restant de s'assurer par construction qu'il ne peut pas se produire.
Une source classique sur le sujet est Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects (aka POSA2) dont on peut trouver des morceaux sur le site d'un des auteurs.

D'une manière générale il faut surtout éviter de se mettre à coller plein de mutex un peu partout, mais au contraire chercher à encapsuler et à minimiser les points de synchronisation entre threads.

MAT.

Citation:

---

Envoyé par zais_ethael

En y regardant d'un peu plus près, il apparait qu'il n'y en a pas de généraliste sur developpez (rhooo, la honte). Mais en cherchant deux secondes sur google celui la a l'air pas mal : http://perso.numericable.fr/~pdeiber...ssus-leger.pdf .

---

désolé j'ai trainé à reprendre le sujet, mais j'ai eu d'autres choses à faire entre temps...

Merci pour ce bon lien. j'ai lu ça avec attention, et j'ai quelques idées à présent de comment fonctionnent les mutex & Cie.

Je vais donc présenter mon probleme autrement : j'ai de 6 à 200 threads qui doivent acceder à une ressource partagée (une pile) pour y ajouter des choses. Cette pile doit se vider dès que possible, avant d'accumuler trop de choses. idéalement elle doit casiment toujours etre vide...
Les threads d'OSG que je vais utiliser sont basés sur les pthreads.

Ma 1ere question concerne le remplissage de la pile pour le moment. chaque thread est désynchronisé par rapport à ses amis, et tous vont chercher à un moment ou un autre, à remplir cette pile de quelques instructions...
j'ai pour le moment créé un mutex, commun à tous les threads, et avant un ajout à la pile je fait un mutex.lock() et je unlock() apres avoir ajouté.

D'une part je ne suis pas sur de savoir si c'est efficace ou non c'est plus ou moins impossible à vérifier...
ensuite, le mutex doit il dépendre d'un thread (ce dont je doute) ou je peux le créer n'importe où ?
Enfin est ce une bonne idée d'utiliser le meme mutex partout pour tous les threads ?

Merci.

Citation:

---

Envoyé par Ange_blond

D'une part je ne suis pas sur de savoir si c'est efficace ou non c'est plus ou moins impossible à vérifier...

---

Ce n'est pas particulièrement inefficace. Si les opérations effectuées par tes threads sont un minimum longues (ce qui devrait être le cas, sinon ça n'aurait pas d'intérêt d'utiliser du multi-thread) ça devrait aller. Et surtout je ne vois pas vraiment d'autre solution, à part de très complexes qui seraient peut être même moins rapides au final.

Citation:

---

Envoyé par Ange_blond

ensuite, le mutex doit il dépendre d'un thread (ce dont je doute) ou je peux le créer n'importe où ?

---

Le principe d'un mutex, c'est justement qu'il soit partagé par plusieurs threads :D. Par contre il n'y en a évidemment qu'un qui peut le créer. Pour ça, autant se tourner vers le thread le plus logique. Si c'est le thread principal de l'application qui va créer tes 200 threads, autant que ce soit lui également qui crée tous les mutexs, variables de conditions, etc... Suivant la convention en C++ qui dit que "ce qu'une entité crée elle doit le détruire", ce sera aussi ce thread qui détruira ton mutex quand il sera devenu inutile (ce n'est en rien obligatoire mais pour s'y retrouver...).

Citation:

---

Envoyé par Ange_blond

Enfin est ce une bonne idée d'utiliser le meme mutex partout pour tous les threads ?

---

Bien sur puisque c'est le but :P

Sinon, ce cas se rapproche plus d'un pattern assez connu qu'est la queue. En gros c'est une collection protégée par un mutex dans laquelle un ou plusieurs threads vont écrire et un ou plusieurs vont lire (exactement comme toi). Néanmoins ce pattern utilise également deux variables de condition : une pour faire bloquer les threads lecteurs si aucune donnée n'est disponible (pour pas qu'ils se retrouvent sans donnée à traiter et sans savoir quoi faire), et une pour bloquer les threads écrivains si il n'y a plus de place dans la collection (rien n'oblige à faire une collection de taille limitée, mais ce n'est pas une mauvaise idée dans le sens où si tes threads écrivains sont plus rapides que les threads lecteurs ça peut éventuellement surcharger la mémoire au bout d'un temps).

Question : pourquoi une pile? Une liste fifo je comprendrais parfaitement mais une pile... c'est un choix un peut étrange. Généralement on part du principe "une donnée est traitée par un thread, elle est donnée à un autre aussi vite que possible". Avec une pile, certaines données vont être traitées du début à la fin très rapidement et d'autres peuvent subir une partie du calcul au tout début du lancement de threads et l'autre tout à la fin de leur cycle de vie.

Les systèmes de transmission de messages (actor model ou même des trucs plus léger comme active object ou les futures) permettent un système plus sûr, plus fiable, et plus facile à programmer.
Par contre c'est pas forcément optimal.

Citation:

---

Envoyé par zais_ethael

Question : pourquoi une pile? Une liste fifo je comprendrais parfaitement mais une pile... c'est un choix un peut étrange. Généralement on part du principe "une donnée est traitée par un thread, elle est donnée à un autre aussi vite que possible". Avec une pile, certaines données vont être traitées du début à la fin très rapidement et d'autres peuvent subir une partie du calcul au tout début du lancement de threads et l'autre tout à la fin de leur cycle de vie.

---

En fait j'abuse un peu du langage en parlant de pile... en terme d'implémentation c'est une classe équipée de méthodes et avec pour seul membre une std::queue

Le choix de la liste FIFO est justifiée par le caractere meme des informations stockées au sein de cette piles, qui se trouvent etre des instructions à réaliser dans un scenegraph, en meme temps que le parcours du graph en question, par de nombreux threads non synchronisés.
Avec la FIFO, j'évite de modifier le graph en plein parcours de ce dernier, et donc je soigne un bug important de crash aléatoire du systeme...

Le fonctionnement est simple : mes threads accumulent les instructions dans la pile, de maniere ordonnée et synchronisée (à présent) et régulierement la pile se vide, de maniere non synchronisée avec les threads, d'où les mutex pour éviter les ajouts dans la pile en meme temps que la vidange de cette derniere.

Apparemment les résultats on l'air bon, je vais à présent tenter de créer un thread associé à la pile, qui permettra de la vidanger de maniere synchronisée avec les threads qui la remplissent et non selon le taux de rafraichissement de la boucle de rendu.

J'ai trouvé l'inspiration ici :http://franckh.developpez.com/tutoriels/posix/pthreads/ pour ceux que ça interesserait.

Pour info, il y a dans les thread building blocks une queue pouvant être utilisée en parallèle.

Citation:

---

Envoyé par JolyLoic

Pour info, il y a dans les thread building blocks une queue pouvant être utilisée en parallèle.

---

Sympa, merci.
Mais je dois faire avec les moyens du bord. C'est un projet professionnel et les outils ont déjà été choisis. D'autant que j'ai des libs basé sur les pthreads à disposition...

Mais merci pour le lien quand meme, sait on jamais ;)

Re,

alors une petite mise à jour sur mon probleme :

Ma ressource partagée est dans un thread, et la méthode run() est ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

virtual void run() { while(true) {   _condition->wait(_mutex); _mutex->lock();   flush();   _mutex->unlock(); _condition->broadcast();   } }

---

Le mutex (_mutex) est membre de ma ressource partagée.

Dans les threads exterieurs, chacun se contente de faire un :

Code:

---

1 2 3 4 5 6 7 8 9

... _stack->_mutex->lock();   _stack->addOnStack(...); _stack->addOnStack(...);   _stack->_mutex->unlock(); ...

---

Je crain un blockage... du genre que le thread de la ressource partagée (pile) attend sur lui meme... enfin je ne sais pas trop...

et vous, vous feriez comment ? pour que la pile appelle le flush regulierement, en prenant soin de le pas lancer un flush() si un thread est en train d'ajouter des infos sur cette derniere, et que l'appel à ce flush soit indépendant d'une quelconque boucle (d'où le thread)

Merci?

Salut,

Déjà au lieu de faire des lock/unlock manuellement tu devrais utiliser des ScopedLock pour faire du RAII, par ex :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

virtual void run() { while(true) { _condition->wait(_mutex); { OpenThreads::ScopedLock<OpenThreads::Mutex> lock( _mutex ); flush(); } _condition->broadcast(); } }

---

C'est un bon réflexe à prendre, ça évite qu'un unlock ne se fasse pas (parce qu'on l'oublie ou parce qu'une exception est lancée entre temps).

MAT.

Certes je pourrais toujours remplacer mes mutexs, mais dans l'immédiat c'est juste un peu plus lisible pour moi.

Par contre, de toute évidence le wait() n'est jamais franchi... qu'est ce qui pourrait en etre la cause ?

Heuu en fait en regardant de plus pres j'ai modifié mon run ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

virtual void run() { while(true) {   _mutex->lock(); _condition->wait(_mutex);   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

et j'ai ajouté dans mes acces en écriture situé dans les threads un signal()... certainement le signal qu'attendait mon wait()...

Bref ça a l'air de tourner comme il faut à présent.
Merci.

Je pense que j'en ai terminé avec les threads, faute de quoi je viendrai dépoussierer le topic.

Merci à tous de votre aide.

Il y a une technique spécifique pour l'utilisation des variables de condition. Voila l'algo:

Code:

---

1 2 3 4 5 6

mutex.lock(); while(is_it_good_to_continue()) { condition.wait(); } operation(); mutex.unlock();

---

Comme le mode de fonctionnement exact d'une variable de condition est soumis à interprétation (si je fais un signal puis juste après un wait je suis bloqué ou pas?) il vaut mieux se méfier. Cet algo permet de gérer tous les cas de figure, même si un signal() est effectué quand il n'aurait pas du.

Par contre je comprends moyennement ta méthode broadcast. En admettant que ce soit un autre nom pour l'opération signal(), à quoi cela peut-il servir si le wait() et le signal() sont effectués par le même thread?

le wait() et le signal ne sont pas effectués par le meme thread... d'où ce broadcast() qui est un "signal()" à tous les threads en attente...

Citation:

---

Envoyé par Ange_blond

le wait() et le signal ne sont pas effectués par le meme thread... d'où ce broadcast() qui est un "signal()" à tous les threads en attente...

---

Donc le broacast c'est un signal... Dans les morceaux de code que tu nous as collé, c'est le même thread qui fait le wait et broadcast, ça n'a pas de sens. Ce qu'on désire quand on utilise une variable de condition c'est qu'un thread se retrouve bloqué et qu'un autre le libère.
Tu n'as peut être pas collé tout ton code. Ce qu'il serait intéressant si tu veux qu'on puisse commenter ton code serait que tu nous désignes précisément les morceaux de code liés aux threads "lecteurs" et aux threads "écrivains" (ça n'a pas d'importance de savoir lequel initialise une ressource à la base ou lequel est le thread principal) ainsi que le nombre de ces threads des deux cotés (un ou plusieurs?).

heuu, he bien selon moi tout marche bien là, mais dans un soucis de comprendre tout oui voilà :

Sur ma pile : Unique thread dont le run() est :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

virtual void run() { while(true) {   _mutex->lock(); _condition->wait(_mutex);   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

Qui accedent à la pile : plus de 150 threads (nombre variable) dont le code ressemble à :

Code:

---

1 2 3 4 5 6 7 8 9 10

[...] _mutex->lock();   addonstack(....);   _mutex->unlock();   _condition->signal(); [...]

---

Voilou.

Remarque sans rapport direct avec ta question :
Je ne sais pas ce que tu as comme machine, mais une appli de plus de 150 threads sur une architecture classique n'est probablement pas optimale, et va passer plein de temps à basculer d'un thread à l'autre.

Ha, la alors ça me semble correct.
Néanmoins il me semble important de modifier le code de ton lecteur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

virtual void run() { while(true) {   _mutex->lock(); while(stack_is_empty()) { _condition->wait(_mutex); }   flush();   _condition->broadcast(); _mutex->unlock();   } }

---

Une variable de condition n'est pas à proprement parler une condition. C'est un dispositif qui permet de bloquer un thread jusqu'à ce qu'un autre décide de lui signaler que l'état d'une condition a potentiellement changé.
Dans les tests que tu as effectué, tu as peut être eu de la chance mais selon moi ce n'est pas sensé fonctionner comme ça.
Imaginons un cas comme un autre : un thread écrivain ajoute un seul objet à la liste et fait un signal, par la suite plus aucun nouvel objet ne sera ajouté. Ensuite ton thread lecteur fait un wait, il peut donc se retrouver bloqué éternellement suivant le comportement de l'api de thread utilisé, puisque plus aucun autre signal n'aura lieux. Pourtant il y a une donnée dans la liste -> donc c'est une erreur.

Citation:

---

Envoyé par zais_ethael

Imaginons un cas comme un autre : un thread écrivain ajoute un seul objet à la liste et fait un signal, par la suite plus aucun nouvel objet ne sera ajouté. Ensuite ton thread lecteur fait un wait, il peut donc se retrouver bloqué éternellement suivant le comportement de l'api de thread utilisé, puisque plus aucun autre signal n'aura lieux. Pourtant il y a une donnée dans la liste -> donc c'est une erreur.

---

Certes, j'ai bien remarqué la chose, mais dans l'utilisation normale du programme, la pile ne risque pas de refroidir beaucoup... mais je vais néanmoins corriger ça pour que ce soit clean.

Merci

Citation:

---

Envoyé par JolyLoic

Je ne sais pas ce que tu as comme machine, mais une appli de plus de 150 threads sur une architecture classique n'est probablement pas optimale, et va passer plein de temps à basculer d'un thread à l'autre

---

La base des 150 thread avait déjà été mis en place avant que je commence à m'interesser à la synchro... cependant ils sont legers et sont aussi nombreux pour pouvoir lancer des telechargements simultanés, tout simplement... pas de soucis sur ma machine (puissante) ça tourne plutot bien :-)

Merci à tous pour votre aide et vos conseils :D