Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 9 sur 9
  1. #1
    Membre régulier
    Inscrit en
    novembre 2006
    Messages
    350
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 350
    Points : 79
    Points
    79

    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
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    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 718
    Points : 3 026
    Points
    3 026

    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/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    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
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    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 718
    Points : 3 026
    Points
    3 026

    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
    Inscrit en
    novembre 2006
    Messages
    350
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 350
    Points : 79
    Points
    79

    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
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 677
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 677
    Points : 15 708
    Points
    15 708

    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 Expert
    Avatar de white_tentacle
    Inscrit en
    novembre 2008
    Messages
    1 265
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 1 265
    Points : 1 717
    Points
    1 717

    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
    Inscrit en
    novembre 2006
    Messages
    350
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 350
    Points : 79
    Points
    79

    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
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    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 718
    Points : 3 026
    Points
    3 026

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •