IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

Singleton - multithread - protection donnees - conteneurs stl


Sujet :

Threads & Processus C++

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    366
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 366
    Points : 116
    Points
    116
    Par défaut Singleton - multithread - protection donnees - conteneurs stl
    Bonjour,

    Une petite question sur la gestion des données via les conteneurs de la stl et iterateurs que je n'ai pas l'habitude d'utiliser.

    J'ai un gestionnaire de données qui interprète et stocke ses données dans des vecteurs set map etc..
    Les differents thread de mon appli peuvent le requêter pour les récupérer (faire des recherches etc mais pas d'insertions [pour l'instant])
    Je voulais donc passer mon gestionnaire en singleton.
    Est ce que le travail qui est fait sur les recherches dans les conteneurs avec iterateur est thread safe ?

    Concernant le problème du double check, peut on le résoudre en confiant son initialisation (donc creation) au main thread et faire seulement un getInstance dans les autres threads ?

    Certains disent qu'un singleton est le resultat d'une mauvaise conception, y a t il d'autres solutions pour gerer par exemple le cas decrit ici ?

    => Creation d'une table de données a partir des parametres due recoit l'appli
    => Utilisation de ses donnees dans les threads de calcul

    Merci d'avance
    Bonne fin de journee

  2. #2
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Citation Envoyé par sone47 Voir le message
    Est ce que le travail qui est fait sur les recherches dans les conteneurs avec iterateur est thread safe ?
    Non, aucun conteneur de la bibliotheque standard n'est thread-safe. Au mieu, si tu as un conteneur en acces const qui n'est jamais modifie, tu peux le lire via plusieurs threads. Si il est modifiable a un moment ou un autre, il te faut entourer son acces de mutex, ou passer a des conteneurs fait pour ca.

    Le truc a comprendre c'est que selon si le conteneur est fait ou pas pour des acces concurentiels, son interface et son fonctionnement vont pas du tout etre pareil pour maintenir des guaranties. Donc il va falloir attendre avant d'en avoir dans la STL et tu peux etre sur qu'ils seront differents de ceux qu'on a pour l'instant.

    Si tu utilses TBB, ils ont des containeurs a acces concurrentiel. Boost a LockFree qui fournis 3 conteneurs (different de ceux de TBB d'ailleurs).

    Concernant le problème du double check, peut on le résoudre en confiant son initialisation (donc creation) au main thread et faire seulement un getInstance dans les autres threads ?
    J'ai pas capte ce que tu demandes la.

    Certains disent qu'un singleton est le resultat d'une mauvaise conception, y a t il d'autres solutions pour gerer par exemple le cas decrit ici ?
    C'est discutable: le singleton est problematique si il sa construction et sa destruction ne sont pas deterministes OU si passer l'objets aux differents systemes n'est pas plus contraignants.

    En gros tu pourrais passer un pointeur vers ton objet a tous tes threads. Le probleme c'est que si ca deviens fastidieux niveau du code, alors ya pas de souci a avoir un singleton, mais fais juste en sorte que sa creation et destruction soit bien explicite, pas automatique.

    Certain dirons de totalement virer les singleton, auxquels je repondrais que les regles absolues survivent rarement aux contextes extremes.

    En gros, te soucie pas de faire ou pas un singleton, ton probleme c'est que tu as des acces concurentiels a un systeme. Il te faut proteger ce systeme sauf si tu es sur qu'il sera en lecture seule pendant toute sa vie apres construction.

    Note: depuis C++11, un objet statique est construit et detruit de maniere "atomique" ce qui fait que tu es garanti qu'il sera construit et detruit qu'une fois meme si plusieurs threads y accedent. En fait le compilo va ajouter un lock pour proteger construction et destruction de l'objet.

  3. #3
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Salut,
    Citation Envoyé par Klaim Voir le message
    Concernant le problème du double check, peut on le résoudre en confiant son initialisation (donc creation) au main thread et faire seulement un getInstance dans les autres threads ?
    J'ai pas capte ce que tu demandes la.
    je pense qu'il parle du problème du double check lors de la construction passive du constructeur. Cf le Singleton du tuto de david.
    Effectivement, une solution est de construire les objets dans le main avant la création des autres threads. Il n'y a plus besoin de check du tout à ce moment.

    Citation Envoyé par Klaim Voir le message
    C'est discutable: le singleton est problematique si il sa construction et sa destruction ne sont pas deterministes OU si passer l'objets aux differents systemes n'est pas plus contraignants.

    En gros tu pourrais passer un pointeur vers ton objet a tous tes threads. Le probleme c'est que si ca deviens fastidieux niveau du code, alors ya pas de souci a avoir un singleton, mais fais juste en sorte que sa creation et destruction soit bien explicite, pas automatique.
    Dans une problématique multithread, cela n'a pas d'intérêt car distribuer un pointeur ne va pas éliminer les problèmes d'accès concurrents. De plus, un singleton est d'abord une variable globale qui rend les fonctions l'utilisant non pures et donc difficiles à tester, maintenir et réutiliser.

    Citation Envoyé par Klaim Voir le message
    Certain dirons de totalement virer les singleton, auxquels je repondrais que les regles absolues survivent rarement aux contextes extremes.
    L'idée pourrait être qu'est ce qui dans le design impose l'utilisation d'un singleton au détriment d'une solution ne l'imposant pas ? Si on n'a pas de réponse valable à cette réponse alors autant ne pas utiliser un singleton.

    Citation Envoyé par Klaim Voir le message
    En gros, te soucie pas de faire ou pas un singleton, ton probleme c'est que tu as des acces concurentiels a un systeme. Il te faut proteger ce systeme sauf si tu es sur qu'il sera en lecture seule pendant toute sa vie apres construction.
    yep

  4. #4
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    L'idée pourrait être qu'est ce qui dans le design impose l'utilisation d'un singleton au détriment d'une solution ne l'imposant pas ? Si on n'a pas de réponse valable à cette réponse alors autant ne pas utiliser un singleton.
    Tout a fait d'accord. Du coup, en pratique dans l'autre sens, c'est toujours mieu de partir d'abord du principe qu'on a pas besoin du Singleton, jusqu'a ce que ca devienne problematique que ce soit pas un Singleton. C'est plus facile de passer un objet/type en Singleton apres qu'on ai commence a l'utiliser que l'inverse.

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    366
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 366
    Points : 116
    Points
    116
    Par défaut
    Merci a vous pour ces reponses.

    Citation Envoyé par Klaim Voir le message
    Non, aucun conteneur de la bibliotheque standard n'est thread-safe. Au mieu, si tu as un conteneur en acces const qui n'est jamais modifie, tu peux le lire via plusieurs threads. Si il est modifiable a un moment ou un autre, il te faut entourer son acces de mutex, ou passer a des conteneurs fait pour ca.

    Le truc a comprendre c'est que selon si le conteneur est fait ou pas pour des acces concurentiels, son interface et son fonctionnement vont pas du tout etre pareil pour maintenir des guaranties. Donc il va falloir attendre avant d'en avoir dans la STL et tu peux etre sur qu'ils seront differents de ceux qu'on a pour l'instant.

    Si tu utilses TBB, ils ont des containeurs a acces concurrentiel. Boost a LockFree qui fournis 3 conteneurs (different de ceux de TBB d'ailleurs).
    Ok je note, pour ma part acces const, pas de modif, donc je peux laisser tel quel.

    Citation Envoyé par 3DArchi Voir le message
    Salut,
    je pense qu'il parle du problème du double check lors de la construction passive du constructeur. Cf le Singleton du tuto de david.
    Effectivement, une solution est de construire les objets dans le main avant la création des autres threads. Il n'y a plus besoin de check du tout à ce moment.
    C'est vers quoi je me suis orienté, un manager qui crée mon instance et tout les threads n'ont qu'a faire un getInstance qui ne fais plus de creation d'objet.

    Merci encore a vous.
    ++

  6. #6
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Salut
    Citation Envoyé par Klaim Voir le message
    Tout a fait d'accord. Du coup, en pratique dans l'autre sens, c'est toujours mieu de partir d'abord du principe qu'on a pas besoin du Singleton, jusqu'a ce que ca devienne problematique que ce soit pas un Singleton. C'est plus facile de passer un objet/type en Singleton apres qu'on ai commence a l'utiliser que l'inverse.
    Alors, ce serait plutôt un monostate qu'un singleton, car, si tu dois commencer à changer tous les appels de TonObjet obj; en TonObjet::instance() (voir en TonObjet & obj=TonObjet::instance() ), ca risque de faire mal, surtout si tu travailles sur un bibliothèque utilisée par d'autres

    Ceci dit, j'aimerais bien que sone47 nous explique pourquoi il voudrait transformer son gestionnaire en singleton, s'il n'a pas eu besoin de ce patron jusqu'à présent

    Je dois avouer que je nourris certains doutes par rapport au bien fondé de cette décision
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #7
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 505
    Points : 2 799
    Points
    2 799
    Par défaut
    Citation Envoyé par sone47 Voir le message
    C'est vers quoi je me suis orienté, un manager qui crée mon instance et tout les threads n'ont qu'a faire un getInstance qui ne fais plus de creation d'objet.
    Dans ce cas, fais en sorte que getInstance ne renvoie pas une référence, mais une référence constante. Et une méthode spécifique pour l’initialisation.

    Comme l’a dit Koala, ce n’est plus vraiment un singleton ce que tu as.

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    366
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 366
    Points : 116
    Points
    116
    Par défaut
    Bonjour,

    En fait je ne connaissais pas monostate donc je vais regarder de ce coté la.
    Peut etre c'est juste un abus de langage le fait que j'appelle cela un singleton car dans les faits je ne l'utilise pas tel quel.

    Mon Manager principal créé des gestionnaires de données qui pour moi sont des songletons, et remplit leurs données.

    Ce manager lance X threads qui eux peuvent faire appel a n'importe quel gestionnaire de données par un gestionnaireDonneesX::getInstance(), gestionnaireDonneesY::getInstance().

    Toutes les donnees sont const donc pas de modif.

    Est ce qu'il ya un probleme a faire ça ?
    Le terme singleton n'est donc pas bon pour designer ce type de comportement ?

    Merci d'avance

  9. #9
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Si tu es absolument garanti que les donnees utilisees par les threads ne bougent pas d'un pouce apres que les threads soient lances, alors tu n'as pas besoin de mecanisme de synchronisation. Pour le garantir, il faut que tu fasses en sortes que les threads soient bien lances exclusivement apres le remplissage des donnees, ET qu'ils ne peuvent jamais acceder a l'interface de tes objets en non-const.

    Sinon, il y aura synchronisation quelque part.

    Le terme singleton n'a rien a voir avec ca, c'est un sujet en realite separe, mais qui peut empirer les choses disons.

    Je serais toi, je passerai un objet contenant les reference const a tes objets fournissant les donnees a tes threads, de maniere a1. pas besoin de singleton 2. l'acces est garanti const (sauf si tu fais un const cast mais alors la c'est toi qui fou la merde si je puis dire), 3. permet de garantir que tant que ton objet es tpas construit avec les dites donnees, tu peux pas le fournir aux threads.

Discussions similaires

  1. Conteneurs STL et références
    Par rockeye dans le forum SL & STL
    Réponses: 11
    Dernier message: 10/07/2008, 19h07
  2. Conteneurs STL : passage d'arguments par référence
    Par bolhrak dans le forum SL & STL
    Réponses: 0
    Dernier message: 26/09/2007, 21h54
  3. Réponses: 12
    Dernier message: 16/08/2006, 23h28
  4. type conteneur stl
    Par star_light dans le forum SL & STL
    Réponses: 5
    Dernier message: 16/02/2005, 00h51
  5. Fonction polymorphe et conteneur stl.
    Par Captain Fizzou dans le forum SL & STL
    Réponses: 2
    Dernier message: 29/11/2004, 20h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo