Discussion :

[Charlemagne]

Je voudrais "multithreader" un programme, mais y'a quelques variables statiques que je ne peux/veux pas �ter.
Comment faire pour que chaque thread ait ses propres donn�es statiques et �viter ainsi les conflits?

J'ai vu le "Thread Local Storage" (TLS) sous Visual, mais �a m'a pas l'air applicable � d'autres syst�mes.

Vos suggestions doivent �tre dans la mesure du possible:
-applicables sous diff�rents syst�mes (Windows,Linux,Unix)
-faciles � mettre en oeuvre

Merci par avance!

[alskaar]

tu peux imaginer un classe singleton qui renvoie une instance en fonction du numero de thread

[loufoque]

J'ai vu le "Thread Local Storage" (TLS) sous Visual, mais �a m'a pas l'air applicable � d'autres syst�mes.

C++ n'a aucune notion de multithreading, donc tout ce que tu fais d�pend du syst�me.

[mchk0123]

En C++ toute variable statique (quelle soit de port�e globale ou de classe) existe une et une seule fois pour l'ensemble d'un programme.

Donc avoir une variable statique (unique) dupliqu�e autant de fois qu'il y a de thread, ce n'est pas possible.

Le meilleur moyen pour cela c'est de cr�er une classe qui ressemble � ce que fait un Singleton (comme l� dit alskaar), mais qui se rapproche plus d'un Proxy avec allocation � la demande index� par ton ThreadID courant (qui peut toujours �tre r�cup�r� simplement quelque soit l'architecture). Pour rechercher l'association ThreadID <-> Instance Singleton, utilise un std::map.

[Charlemagne]

Je sais bien tout ce que vous me dites.
Mais je crois bien savoir qu'il existe un truc standard (probablement POSIX) qui g�re les variables globales/statiques pour diff�rents threads. Certes, c'est du C. Mais j'arrive pas � le retrouver. J'esp�rais que l'un d'entre vous le connaisse...

[Charlemagne]

Finalement, apr�s quelques recherches, il semble que le TLS soit int�gr� � la plupart des compilos (peut-�tre m�me tous).
La syntaxe varie peut-�tre un peu d'un compilo � l'autre, mais rien qu'une ou deux macros ne puissent corriger.
Je pr�f�re utiliser le TLS plut�t que tout reprogrammer moi m�me...

[mchk0123]

C'est vrai que la TLS est s�duisante.

Maintenant, si sa portabilit� est d'aussi bonne qualit� que les pthreads & co. () �a va pas �tre si �vident que �a !

[Charlemagne]

Maintenant, si sa portabilit� est d'aussi bonne qualit� que les pthreads & co. () �a va pas �tre si �vident que �a !

Au moins le TLS est/semble int�gr� aux compilos.
J'ai pas encore compil� et v�rifi� si �a marche, mais en tout cas sur le papier rien de plus simple.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
static __thread int tls_i; // GCC
static __thread __declspec( thread ) int tls_i; // Visual & Intel

Je vais d�clarer une macro dans mon fichier de configuration

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
#if defined(__ICL) || defined(_MSC_VER)
  //#define __thread // single-threaded
  #define __thread __declspec( thread ) //multithreaded
#elif defined (__GNUC__)
  //#define __thread // single-threaded
#endif

En ce qui concerne les pthreads & co., chaque chose en son temps...

[Luc Hermitte]

win32 -> TLS
pthreads -> TSD (thread-Specific Data)
Matthew Wilson, dans son Imperfect C++, les r�unit sous le terme TSS (Thread-Specific Storage).

Visiblement, il a encaspcul� le tout, et je soup�onne que cela se trouve dans sa biblioth�que STLSoft.

[mchk0123]

Voil� qui devient int�ressant (je ne m'�tait pench� sur les pthreads depuis 10 ans, certains devait d�j� conna�tre) :

http://sources.redhat.com/pthreads-win32/

Je ne l'ai pas test� mais cela laisse envisager une possibilit� d'�crire des TLS de mani�re portable.

[Mat007]

Sinon dans boost.thread il y a une partie pour g�rer du 'thread specific storage', suppos�e portable, mais je n'ai jamais essay� de l'utiliser...

MAT.

[Charlemagne]

Visiblement avant d'�tre int�grer � divers compilos, il y avait une API propre � chaque syst�me pour g�rer les variables globales/statiques de chaque thread.

Le TLS/TSD/TSS, c'est malheureusement pas encore parfait: VC8 et ICL se plaignent: "object with constructor or destructor cannot be declared 'thread'".
C'est vraiment trop idiot. Moi qui ai 2 ou 3 maps statiques (qui gardent en m�moire des r�sultats interm�diaires pour ne pas avoir � tout recalculer lors des appels de fonctions suivants), il va falloir que je trouve une id�e. J'ai pas l'intention d'abandonner le principe du TLS car la syntaxe est quand m�me pratique.
Toute suggestion est la bien venue. Peut-�tre remplacer d'une mani�re ou d'une autre les maps par des tableaux C.

Voil� qui devient int�ressant (je ne m'�tait pench� sur les pthreads depuis 10 ans, certains devait d�j� conna�tre) :

http://sources.redhat.com/pthreads-win32/

Moi je trouvais int�ressante la petite biblioth�que dont quelqu'un faisait un peu de pub dans cette discussion: http://www.developpez.net/forums/sho...d.php?t=293814
Je l'ai pas essay�. Je sais pas si elle est portable (Windows/Unix/Linux) mais �a en a ben l'air.
J'avais l'intention de m'en inspirer: vu que je n'ai besoin que de threads ind�pendants pour du calcul num�rique, j'ai pas besoin de trucs compliqu�s (mutex, s�maphores...).

Je ne l'ai pas test� mais cela laisse envisager une possibilit� d'�crire des TLS de mani�re portable.

A priori, si j'en crois les docs, le TLS est d�j� portable.

Sinon dans boost.thread il y a une partie pour g�rer du 'thread specific storage', suppos�e portable, mais je n'ai jamais essay� de l'utiliser...

Dans la doc de la petite biblioth�que mentionn�e ci dessus, j'adh�re � l'argumentation suivante:

Nous avons h�sit� � utilise la librairie thread du projet Boost. Cette librairie propose une impl�mentation C++ des threads POSIX. Par rapport � la version standard des threads POSIX �crite en C, cette version nous aurait offert certaines simplifications au niveau des op�rations li�es � la gestion des threads. Nous avons cependant d�cid� de ne pas utiliser cette librairies pour les raisons suivantes:
- tr�s peu d'instructions sont utilis�es dans le code MPTL pour g�rer les threads;
- l'utilisation de la librairie thread de Boost implique une forte d�pendance pour faire fonctionner la MPTL

[Charlemagne]

Voil�, j'ai fais plusieurs essais avec le "Thread Local Storage", et malheureusement, c'est pas la panac�e.

Ca marche avec les compilos ICL et VC8 (sous r�serve de ne pas rendre statique une classe avec constructeur/destructeur).
Mais GCC 4.1.2 sous Windows n'accepte pas le TLS: "error: thread-local storage not supported for this target"

Est-ce que vous pouvez essayer de d�clarer une telle variable statique avec un GCC sous Linux/Unix ou tout autre compilateur SVP? Merci

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

static __thread int tls_i=0;

Ou mieux, si quelqu'un peut me dire comment faire en sorte que �a marche avec GCC...

[M�dinoc]

Tu peux toujours utiliser le Thread-Local storage dynamiquement et non statiquement, avec les fonctions d�di�es : Sous Windows, il s'agit de TlsAlloc(), TlsSetValue(), etc.

Il suffit d'une variable globale ou statique qui contiendra l'index de TLS...

[Charlemagne]

Tu peux toujours utiliser le Thread-Local storage dynamiquement et non statiquement, avec les fonctions d�di�es : Sous Windows, il s'agit de TlsAlloc(), TlsSetValue(), etc.

C'est l'API dont je parle un peu plus haut, mais justement je veux un programme:
- compilable sous divers OS
- le moins de d�pendance possible vis-�-vis de librairies non standards (Boost...)
- aussi simple que possible.

En plus, j'ai d�j� pas mal investi dans le TLS avec des changements pour r�crire les classes statiques en des structures C. Ca marchait bien et puis j'ai compil� avec GCC...
En tout cas c'est un probl�me de GCC, donc avec un peu de chance le probl�me dispara�tra de lui m�me dans l'avenir. C'est peut-�tre une option de compilation manquante, un probl�me li� au syst�me, etc...

Si quelqu'un peut tester si le TLS fonctionne sous d'autres OS que Windows, �a m'int�resse...

[Luc Hermitte]

Dans nos projets, il y a toujours des services de base que le langage manque de nous rendre. Il ne me parait pas hallucinant d'utiliser des biblioth�ques qui rendent ces sevices. Cela me parait toujours mieux que de donner dans un syndrome du NIH qui va, ici, tenter d'abstraire les diverses plateformes cibles.

Surtout que des trucs comme boost sont suffisament devenus classiques.
Suivant les licences, tu peux toujours regarder comment ils ont fait
-> http://synesis.com.au/software/stlso...ss__index.html [TSS pour win32]
-> http://synesis.com.au/software/stlso...ss__index.html [TSS pour *nix (pthread?)]
-> http://www.boost.org/doc/html/thread_specific_ptr.html [chez boost]

[Charlemagne]

L� n'est pas la question. Mais j'�vite quand m�me les d�pendances vis � vis de biblioth�ques non standard. Je vois tout un tas de bonnes raisons:
- pas toujours facile � installer, souvent laborieux m�me quand on conna�t pas.
- il faut les remettre � jour.
- pas toujours compatible d'un OS � l'autre, d'un compilo � l'autre
- il faut que chaque utilisateur de mon projet les installe
- Quasi impensable de modifier soi m�me les sources de biblioth�ques externes en cas de probl�me (ou sinon apr�s de longues analyses), alors que modifier son propre code est si facile
- la biblioth�que ne correspond pas forc�ment exactement � ce que l'on d�sire

Bref je souscris � l'analyse qu'avait �galement fait l'auteur de la petite biblioth�que MPTL que je cite ci dessus.
Alors je pr�f�re programmer moi m�me � mon id�e les quelques rares �l�ments dont j'ai besoin et que Boost int�gre.
J'ai rien contre Boost en particulier, mais je ne l'utiliserai pas avant qu'il ne soit livr� d'office avec tout bon compilateur.

En ce qui concerne le TLS, il semblerait que seul la version Windows de GCC ne le supporte pas, va savoir pourquoi. Mais que �a marche bien sous d'autres syst�mes. Je peux faire avec. Je pr�f�re de loin utiliser les instructions des compilos � toute biblioth�que.
Mais j'aimerais bien que quelqu'un me confirme que �a marche sous Linux/Unix...

[Luc Hermitte]

A partir du moment o� le mot cl� commence par deux underscores, je suis tr�s m�fiant..
Alors qu'une solution qui encapsule une biblioth�que peut se reposer sur cette biblioth�que (pthread et win32 ont je pense une excellente couverture du march� � elles deux), celles qui reposent sur un mot cl� propri�taire qui est d�pendant de chaque compilo va AMHA �tre plus vite limit�e (� cause du nombre de compilos diff�rents).

Si Matthew Wilson et d'autres auteurs (D.C.Schmidt) ont choisi de reposer sur les biblioth�ques plut�t que les OS, � mon avis ce n'est pas innocent -- M.W. est le seul auteur � ma connaissance � avoir sorti un bouquin qui contient plusieurs chapitres dont le sujet est une variation de "comment faire XXX sous 15 compilos/environnements diff�rents".

J'avoue que je serais tr�s curieux de savoir pourquoi s'il existe ce mot cl�, ces auteurs (non des moindres) ont choisi la solution biblioth�que. Je ne trouve pas grand chosqe sur google. On dirait que c'est d� au fait que le mot cl� ne soit pas pr�sent partout (bien que tr�s r�pandu � en lire http://www.open-std.org/jtc1/sc22/wg...005/n1815.html)

M�me si tu tiens absolument � r�inventer la roue, tu peux regarder comment les autres roues tournent -- et je ne dis pas �a parce que je suis tr�s m�fiant (et rarement emball� par) des biblioth�ques qui r�iventent la roue.

PS: le compilo de Sun semble suivre la m�me voie que GCC -- pardon, c'est le contraire.
PPS: Je vois que Douglas C. Schmidt (Monsieur ACE) a �crit un article 100% orient� biblioth�que sur le sujet -> http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
PPPS: wikip�dia dit autre chose pour intel -> http://en.wikipedia.org/wiki/Thread-local_storage

[Charlemagne]

J'avoue que je serais tr�s curieux de savoir pourquoi s'il existe ce mot cl�, ces auteurs (non des moindres) ont choisi la solution biblioth�que. Je ne trouve pas grand chosqe sur google. On dirait que c'est d� au fait que le mot cl� ne soit pas pr�sent partout (bien que tr�s r�pandu � en lire http://www.open-std.org/jtc1/sc22/wg...005/n1815.html)

Peut-�tre qu'ils r�inventent la roue...

M�me si tu tiens absolument � r�inventer la roue, tu peux regarder comment les autres roues tournent -- et je ne dis pas �a parce que je suis tr�s m�fiant (et rarement emball� par) des biblioth�ques qui r�iventent la roue.

Je consid�re en l'occurrence que c'est plut�t Boost qui ici r�invente la roue si les compilos int�grent d�j� le TLS et si bien d'autres biblioth�ques proposaient auparavant des fonctionnalit�s semblables. Au plus je n'aurais utilis� que 2 ou 3 autres fonctionnalit� de boost...
De toute fa�on j'aime pas Boost et tu ne me feras pas changer d'avis sur l'utilisation de biblioth�ques: les d�pendances sont toujours des nids � probl�mes dont je suis ravis de m'�tre d�barrass� depuis longtemps.
J'ai fais une seule exception: STLport. Mais la raison est surtout historique � cause des trop nombreux bugs dans les impl�mentations de VC6,VC7,et VC71. Par contre, j'ai pas encore vu de probl�mes avec la STL de VC8.

PPS: Je vois que Douglas C. Schmidt (Monsieur ACE) a �crit un article 100% orient� biblioth�que sur le sujet -> http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf

L'article date de 1997... �a relativise quelque peu l'int�r�t.

PPPS: wikip�dia dit autre chose pour intel -> http://en.wikipedia.org/wiki/Thread-local_storage

Ah, tiens, effectivement. j'ai fait l'essai avec ICL et il comprend les 2 syntaxes: celle de GCC et celle de Visual.

Quoi qu'il en soit mon probl�me est r�solu sans gros effort et sans d�pendance � une quelconque biblioth�que, avec une excellente compatibilit� sous divers compilos...

PS: J'ai dis une b�tise: finalement ICL ne comprend que la syntaxe de Visual. Peut-�tre bien que la page de wikip�dia consacr�e au TLS faisait r�f�rence � ICC (sous Linux)

[mchk0123]

Je vais peut �tre dire une b�tise, je suis vraiment pas un guru dans ce domaine ...

De toute fa�on il est inconcevable qu'une notion aussi simple que la TLS ne soit pas standardis�e � plus ou moins long terme.

Luc Hermitte d�sol� d'�tre en d�saccord avec toi, mais la notion de "r�inventer la roue" d�pend ou tu la place :

je ne vois que 3 solutions possibles lorsque qu'une techno n'existe pas encore :
1 - faire soi m�me une biblioth�que que l'on impl�mente diff�remment selon l'archi
2 - utiliser une librairie exterieure
3 - attendre l'adoption du standard

Maintenant rapport � r�inventer la roue :

1 - ok je r�invente la roue � ma sauce � moi, mais quand le standard sera adpot� (il le sera surement) j'aurai gagn� un temps �norme

2 - ok je ne r�invente pas la roue, mais il faut bien voir que si ce n'est pas moi qui la r�invente, c'est les auteurs de la librairie

3 - �a peut avoir du bon d'attendre que tout soit bien balis�

Maintenant j'admet que mon jugement peut �tre biais� par mes "~d�ceptions" avec les premi�res versions de la STL/Port