Singleton - multithread - protection donnees - conteneurs stl

[sone47]

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

[Klaim]

Envoyé par sone47

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.

[3DArchi]

Salut,

Envoyé par Klaim

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.

Envoyé par Klaim

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.

Envoyé par Klaim

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.

Envoyé par Klaim

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

[Klaim]

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.

[sone47]

Merci a vous pour ces reponses.

Envoyé par Klaim

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.

Envoyé par 3DArchi

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.
++

[koala01]

Salut

Envoyé par Klaim

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

[white_tentacle]

Envoyé par sone47

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.

[sone47]

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

[Klaim]

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.