Version imprimable
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!
tu peux imaginer un classe singleton qui renvoie une instance en fonction du numero de thread
C++ n'a aucune notion de multithreading, donc tout ce que tu fais dépend du système.Citation:
J'ai vu le "Thread Local Storage" (TLS) sous Visual, mais ça m'a pas l'air applicable à d'autres systèmes.
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.
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...
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...
C'est vrai que la TLS est séduisante.
Maintenant, si sa portabilité est d'aussi bonne qualité que les pthreads & co. (:mouarf:) ça va pas être si évident que ça !
Au moins le TLS est/semble intégré aux compilos.Citation:
Envoyé par mchk0123
J'ai pas encore compilé et vérifié si ça marche, mais en tout cas sur le papier rien de plus simple.
Je vais déclarer une macro dans mon fichier de configurationCode:
2
En ce qui concerne les pthreads & co., chaque chose en son temps...Code:
2
3
4
5
6
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.
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.
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.
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. :bug: 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.
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=293814Citation:
Envoyé par mchk0123
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...).
A priori, si j'en crois les docs, le TLS est déjà portable.Citation:
Envoyé par mchk0123
Dans la doc de la petite bibliothèque mentionnée ci dessus, j'adhère à l'argumentation suivante:Citation:
Envoyé par Mat007
Citation:
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
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
Ou mieux, si quelqu'un peut me dire comment faire en sorte que ça marche avec GCC...Code:static __thread int tls_i=0;
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...
C'est l'API dont je parle un peu plus haut, mais justement je veux un programme:Citation:
Envoyé par Médinoc
- 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...
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]
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...
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
Peut-être qu'ils réinventent la roue...:lol:Citation:
Envoyé par Luc Hermitte
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...Citation:
Envoyé par Luc Hermitte
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.
L'article date de 1997... ça relativise quelque peu l'intérêt.Citation:
Envoyé par Luc Hermitte
Ah, tiens, effectivement. j'ai fait l'essai avec ICL et il comprend les 2 syntaxes: celle de GCC et celle de Visual.Citation:
Envoyé par Luc Hermitte
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)
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
Les dépendances c'est Charybde, réinventer, c'est Scylla. Deux sources de problèmes à éviter. Je suis toujours mal à l'aise devant les opinions tellement opposées à l'une qu'elles ont l'air d'ignorer les dangers de l'autre.Citation:
Envoyé par Charlemagne
Jadis, le syndrome du NIH frappait tellement fort que j'afficher une opinion tranchée contre était sensé,... tant qu'on avait une action plus nuancée. Mais les choses évoluent et je me demande si le balancier ne va pas passer de l'autre côté.
Je reste encore excessivement méfiant à l'égard du syndrome du NIH.
Certes, à réinventer, quand on reste modeste, on peut apprendre énormément.
D'un autre côté, je constate que souvent on perd un temps fou à recoder des choses qui l'ont déjà été. Et surtout, qui ont déjà été validées. Au moins, cela permet de se concentrer sur la partie métier qui est déjà suffisament complexe pour mériter que l'on parte de briques de "haut" niveau.
J'ai tendance à réserver le "réinventer" aux exercices (qu'ils soient dirigés (TDs) et fassent parti de leçons, ou qu'ils soient personnels pour tester de nouvelles approches ou faire de la veille), et le "réutiliser" au boulot. Quitte à réutiliser le résultat de ces exos en dernier lieu.
PS: oui, ACE est vieux, mais depuis, je n'ai rien observé de sérieux qui révolutionne le boulot de Schmidt. De temps à autres des petites modernisations (boost), mais rien de trascendantal.
Franchement j'aurais mis dans l'ordre inverse. Je préfère récrire (dans un temps raisonnable bien sûr) ce dont j'ai besoin, plutôt que d'utiliser des dépendances.Citation:
Envoyé par Jean-Marc.Bourguet
Si le TLS des compilos n'existait pas, j'aurais programmé les classes moi même plutôt que que d'utiliser celui d'un tiers. J'y vois un avantage de plus de récrire (et non "réinventer") une fonctionnalité (pas du plagiat bien-sûr) : on applique la licence que l'on veut sur son code.
Par contre je ne sais pas ce qu'est le "NIH". c'est quoi?
De toute façon dans cette discussion on me conseillait soit d'utiliser une bibliothèque soit de le programmer moi même, mais personne pour me conseiller sur le TLS qui obtient pourtant largement ma préférence. Basta
NIH c'est l'équivalent anglosaxon de "réinventer la roue", littérallement :
"Not Invented Here"
Déf :
Le syndrome du Not Invented Here (littéralement « non inventé ici ») se rencontre couramment dans le domaine de l'industrie du logiciel. Elle s’emploie lorsque des entreprises ont redéveloppé quelque chose qui existait déjà.
Chose drôle (enfin si on veux, je tremble quand même pour que ce ne soit pas prémonitoire), c'est aussi le nom d'une série TV sur les alertes médicales en cas de propagation de virus.
Dans ce sens, c'est National Health Institute.Citation:
Envoyé par mchk0123
Je déterre ce fil, car je suis tombé sur diverses choses en rapport ces dernières semaines.
Sous Solaris, __thread n'existe que depuis la version 5.9 -- evidemment on est 5.8 au taf'. De plus, cela ne s'utilise pas avec les objets -- j'ai oublié si la limitation est aux PODs ou bien aux petits types. Donc pas de membre
possible. Les solutions d'ACE ou de STLSoft restent d'actualité en ce qui me concerne.Code:__thread std::streambuf m_stream;
Sinon, aujourd'hui je suis tombé sur le lien donné par Jean-Marc au sujet du mailing Post Oxford 2007 (sur fclc++), dedans on voit une référence aux TLS: document N2280.
Voilà.
Oui, j'avais remarqué assez vite cet inconvénient majeur de __thread.Code:De plus, cela ne s'utilise pas avec les objets
Dans mon cas il m'aurait fallu déclarer des vecteurs static dans diverses fonctions. J'ai par conséquent opté pour un pointeur auquel j'alloue de la mémoire.
Le problème c'est que mon programme n'a donc plus l'occasion de libérer cette mémoire par lui même (puisque qu'un pointeur C n'a pas de destructeur) et que je compte sur l'OS pour le faire une fois l'exécution finie.