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 ?