OpenMP et vector : quelles sont les opérations critical ?

**Kaluza** · 04/01/2012, 23h15

Bonjour.

J'aimerai paralléliser un programme qui opère sur des objets dérivés de std::vector et j'aurai voulu savoir quelles étaient les opérations qui doivent être déclarées comme critical (les threads doivent attendre que les autres aient terminé avant de commencer). Tout ce qui est resize/push_back est bien sur critical, mais en est-il de même pour l'accès aux éléments d'un vector commun ? Ou alors tous les threads peuvent faire des ".at(i)" ou "[i]" en même temps sur un même objet (ce que j'espère mais bon je préfère me méfier) ?

**Trademark** · 05/01/2012, 11h49

Les opérations qui nécessitent d'être atomiques sont toutes les opérations qui modifient la structure interne du vector. En bref, les méthodes size, at, [], iterateur, ... ne nécessite pas d'être atomique dans le vecteur.

Maintenant quand tu modifies un élément via la méthode 'at' ou encore l'opérateur '*' sur un itérateur, il faut que ça soit atomique. Mais la responsabilité de l'atomicité de ces opérations incombent à l'utilisateur... car ces opérations ne modifient pas la structure interne du vecteur, ce n'est donc pas sa responsabilité !

**ericd69** · 06/01/2012, 23h58

salut,

en effet, l'idée reste la même quelque soit la nature de ta structure de données multi-éléments et sa façon d'être implémentée:

le besoin d'être synchroniser ne tien qu'au risque que plusieurs threads accèdent en même temps en lecture et écriture au même élément ou si, bien sur, tu modifies la liste des éléments pour faire simple... si tu n'as pas ce risque, vu le traitement qu'ils font, alors pas de soucis...

après une bonne politique de gestion des threads est aussi d'en limiter le nombre en fonction de la capacité du système (1 cœur = 2 threads idéalement) en tenant compte que selon os nombre de threads peuvent déjà tourner... (1 thread par contrôle d'une interface par exemple sous Windows)... on programme alors un gestionnaire de "jobs" qui crée le nombre max de threads voulu et les alimente en job...

que ce soit sous Windows ou Linux, trop de threads tue vite les performances car plus tu en as plus il y aura de commutation de contexte... ça peut faire des démarrage de processus plus ou moins lents...

si tu es sous une des dernières versions de Windows, tu as ce genre de gestionnaires de "jobs" pré implémenté dans l'api et plus efficace généralement que CreateThread ou CreateThreadEx...

la version posix des threads est assez limitée et est là pour faire des trucs plutôt car beaucoup d'option de contexte de création n'existent pas...

**JolyLoic** · 07/01/2012, 01h16

Même si ça ne pos epas de problème de justesse, avoir plein de threads qui accèdent simultanément à des cases d'une vector (ou d'un tableau) proches les unes des autres n'est généralement pas une bonne idée. Le point d'entrée pour plus d'infos sur le sujet est "false sharing". En gros, le cache processeur risque d'introduire un lock dans ces accès, et donc de sérialiser les threads.

**ericd69** · 07/01/2012, 03h06

d'où l'idée de généralement limiter de manière raisonnable le nombre de threads plutôt que d'en générer un par "jobs" comme souvent les gens on le réflexe de faire...

**JolyLoic** · 07/01/2012, 14h01

Certes, il ne faut pas créer un thread par tâche, mais tous les moyens modernes de parallélisation gèrent déjà ça sans que l'utilisateur ait à s'en occuper, ce dernier ne manipule que des tâches (et encore, parfois implicitement, dans un // for), pas des threads.

Il n'empêche que même ainsi, le false sharing est un phénomène totalement orthogonal qui va faire que même en nombre raisonnable, les threads vont tout de même se retrouver sérialisées. Et ainsi, sur une machine à 4 processeurs, tes 1000 tâches réparties en 4 threads tourneront quand même plus lentement que si tu les avais exécutées en 1 thread.

**Jean-Marc.Bourguet** · 07/01/2012, 14h39

Envoyé par JolyLoic

Même si ça ne pos epas de problème de justesse, avoir plein de threads qui accèdent simultanément

en écriture

à des cases d'une vector (ou d'un tableau) proches les unes des autres n'est généralement pas une bonne idée. Le point d'entrée pour plus d'infos sur le sujet est "false sharing". En gros, le cache processeur risque d'introduire un lock dans ces accès, et donc de sérialiser les threads.