Discussion :

[Ange_blond]

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.

[zais_ethael]

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.

[Ange_blond]

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...

[valefor]

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

[icer]

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.

[Ange_blond]

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 ?