Discussion :

[Aspic]

Bonjour,

Je découvre la librairie TBB d'Intel pour la programmation multi-threading. J'ai bien compris comment fonctionne la fonction parallel_for mais je souhaiterais savoir s'il est possible de récupérer un ID unique pour chaque thread qui appelle la lambda ? J'ai vu qu'on pouvait récupérer l'ID du thread mais en fait je veux un ID compris entre 0 et nbThread.

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
 
static int id;
id = 0;
unsigned int nbThread = 4;
unsigned int workPerThreadAjust = NodesToAnalyse.size()/nbThread+1;
tbb::parallel_for( tbb::blocked_range<size_t>(0, NodesToAnalyse.size(), workPerThreadAjust),
	[&](const tbb::blocked_range<size_t>& r) {
		s_mutex.lock();
		std::cout << "Thread ID=" << id << " / Analyse range: " << r.begin() << " -> " << r.end();
		++id;
		s_mutex.unlock();
 
		this->_analyseNode(NodesToAnalyse, r.begin(), r.end(), id-1);
 
	} // fin de la lambda
)

Alors cette solution avec une variable statique pour l'id et un mutex fonctionne très bien mais je trouve que c'est sale et puis cela necessite une synchronisation donc une perte de performance.

La fonction tbb::this_tbb_thread::get_id() ne fonctionne pas car retourne un gros identifiant (celui du thread courant) mais qui n'est pas dans l'intervalle [0, nbThread[

Une idée ?

Merci par avance

[Matt_Houston]

Je ne connais pas cette bibliothèque mais ta solution est tout à fait acceptable. On se fout un peu des conséquences de la synchronisation vu que la section critique est exécutée une seule fois et se trouve en dehors du traitement proprement dit.

[Aspic]

Bonsoir,

Non justement la section critique n'est pas exécutée une seule fois :

Code :

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

1
2
3
4
s_mutex.lock();
		std::cout << "Thread ID=" << id << " / Analyse range: " << r.begin() << " -> " << r.end();
		++id;
		s_mutex.unlock();

Ce code la est appelé X fois en fonction de la granularité demandée pour la boucle for donc de workPerThread dans mon exemple.
Dans mon projet, il se peut que ce soit appelé des milliers de fois d'où mon problème avec le mutex...

Je suis presque sur qu'il existe une solution clean sans mutex mais je ne trouve rien sur internet sur TBB qui n'est pas super bien documenté (à mon sens )

[JolyLoic]

Je ne connais pas TBB en pratique, mais si ton NodeToAnalyze est accessible en random access, je ferais un parallel_for sur des entiers de 0 à NodeToAnalyze.size(), et dans la lambda, j'accèderais à NodeToAnalyze[i].

Mais sinon, ton besoin d'identifiant unique me semble louche...

[Matt_Houston]

Ce code la est appelé X fois en fonction de la granularité demandée pour la boucle for donc de workPerThread dans mon exemple.

Puis-je en déduire alors que cette méthode ne fonctionne pas, puisque ton identifiant va être incrémenté plusieurs fois pour chaque thread ?

Je suis presque sur qu'il existe une solution clean sans mutex mais je ne trouve rien sur internet sur TBB qui n'est pas super bien documenté (à mon sens )

La seule manière de faire ça sans synchronisation serait d'avoir assez de contrôle sur le thread pour l'initialiser avec l'identifiant, ce qui n'est pas forcément le cas avec un parallel for (à voir si la bibliothèque le permet). Une fois le thread lancé c'est bien entendu impossible.

[JolyLoic]

En lisant la réponse de Matt_Houston, je me dis que j'ai peut-être mal compris la question : Est-ce que tu veux un identifiant par tâche lancée (donc si ta boucle a n éléments, n ids différents), ou bien un identifiant par thread sous-jacent qui fait tourner la boucle (donc probablement environ 1 id par core de l'environnement d'exécution). La formulation de ta question me fait penser au 2, mais ta proposition de solution me fait penser au 1...

[Aspic]

Je ne connais pas TBB en pratique, mais si ton NodeToAnalyze est accessible en random access, je ferais un parallel_for sur des entiers de 0 à NodeToAnalyze.size(), et dans la lambda, j'accèderais à NodeToAnalyze[i].

Mais sinon, ton besoin d'identifiant unique me semble louche...

C'est exactement ce que je fais mais l'ID unique me sert pour d'autres ressources partagées entre les threads et grâce à ce ID unique, je n'ai pas besoin de mutex...

Donc pour répondre à ta question, je souhaite un ID unique par tâche lancée, c'est à dire à chaque appel de la lambda. Grâce à TBB, je peux contrôler le nombre de fois que je lance la lambda avec le 3ème paramètre :
tbb::parallel_for( tbb::blocked_range<size_t>(0, NodesToAnalyse.size(), workPerThreadAjust)

Puis-je en déduire alors que cette méthode ne fonctionne pas, puisque ton identifiant va être incrémenté plusieurs fois pour chaque thread ?

Si si ca marche très bien, testé en mettant du debug dans la lambda :

Code :

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

1
2
3
4
s_mutex.lock();
		std::cout << "Thread ID=" << id << " / Analyse range: " << r.begin() << " -> " << r.end();
		++id;
		s_mutex.unlock();

Si j'utilise 8 threads, j'ai bien 8 appels et donc 8 ID uniques dans l'intervalle [0, 8[

[Bousk]

Vue la spécificité du besoin, je doute que tu puisses avoir mieux.
Un tel identifiant de thread n'a aucun sens au sens du thread, il s'agit d'un index de tableau spécifique à ton utilisation des threads, quand bien même cette utilisation est faîte via TBB, rien n'assure que lui utilisera un tableau en interne pour les ranger.

[Aspic]

Vue la spécificité du besoin, je doute que tu puisses avoir mieux.
Un tel identifiant de thread n'a aucun sens au sens du thread, il s'agit d'un index de tableau spécifique à ton utilisation des threads, quand bien même cette utilisation est faîte via TBB, rien n'assure que lui utilisera un tableau en interne pour les ranger.

Oui possible que ce soit trop spécifique, enfin c'est pas très grave non plus, ma solution fonctionne bien mais peut être que c'est la conception qui n'est pas top

Merci en tout cas

[Bousk]

La seule option pour ne pas avoir de lock serait d'utiliser un intrinsic d'incrémentation, par exemple sous VS https://msdn.microsoft.com/en-us/library/2ddez55b.aspx
Peut-être que std::atomic peut être utilisé aussi, mais ça dépendra de l'implémentation je pense.

[gb_68]

Code :

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

1
2
3
4
5
6
7
8
9
	[&](const tbb::blocked_range<size_t>& r) {
		s_mutex.lock();
		std::cout << "Thread ID=" << id << " / Analyse range: " << r.begin() << " -> " << r.end();
		++id;
		s_mutex.unlock();
		
		this->_analyseNode(NodesToAnalyse, r.begin(), r.end(), id-1);
	 
	} // fin de la lambda

Attention tu utilises ton id en dehors de tout mutex !
Après le unlock un autre thread peut très bien l'avoir déjà remodifier.

En multi-threading il vaut mieux travailler le plus possible avec des données propres à chaque thread et faire le moins souvent appel à des données partagés (à moins qu'elles ne soient en lecture seule).

Exemple avec une copie locale de l'id :

Code :

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

1
2
3
4
5
6
7
8
9
10
	[&](const tbb::blocked_range<size_t>& r) {
		int current_id;
                s_mutex.lock();
                current_id = id++;
		std::cout << "Thread ID=" << current_id << " / Analyse range: " << r.begin() << " -> " << r.end();		
		s_mutex.unlock();
 
		this->_analyseNode(NodesToAnalyse, r.begin(), r.end(), current_id);
 
	} // fin de la lambda

Pour te passer des mutex, tu peux aussi regarder du côté des atomic (je ne connais pas ttb, mais apparemment cette bibliothèque en possèdent aussi). [Edit] Grillé par Bousk

[JolyLoic]

Et qu'est-ce qui ne correspond pas dans ma première proposition ?