[HS] Design Patterns : Singleton
Le
Stephane Wirtel
Bonsoir,
J'aurais aimé avoir votre avis sur la question concernant
l'implémentation du Design Pattern "Singleton" dans le cas d'une
application multi-thread.
J'ai pû constater que Mr Douglas C. Schmidt proposait comme solution, le
fait d'employer le Double Checked Locking, mais en faisant une recherche
sur google, j'ai pû constater que des exemples donnaient des résultats
contradictoires concernant ce pattern.
Auriez-vous un conseil à me fournir afin d'implémenter une classe
Singleton qui puissent fonctionner dans un environnement multi-thread ?
Merci,
Stéphane WIRTEL.
J'aurais aimé avoir votre avis sur la question concernant
l'implémentation du Design Pattern "Singleton" dans le cas d'une
application multi-thread.
J'ai pû constater que Mr Douglas C. Schmidt proposait comme solution, le
fait d'employer le Double Checked Locking, mais en faisant une recherche
sur google, j'ai pû constater que des exemples donnaient des résultats
contradictoires concernant ce pattern.
Auriez-vous un conseil à me fournir afin d'implémenter une classe
Singleton qui puissent fonctionner dans un environnement multi-thread ?
Merci,
Stéphane WIRTEL.
Poser une question
L'initialiser *avant* de passer en multi-thread si tu veux eviter les
locks.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++...index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
solutions:
- creer le singleton avant d'etre en multithread
- garantir l'execution unique en multithread (voir pthread_once)
- utiliser des locks (tres lent).
Le DCL ne marche pas de facon portable.
a+, ld.
de cache (X86...). Si tu veux être générique et portable, utilises un lock
pour chaque appel à "GetInstance".
Arnaud
Mais j'ai tout de même une question, le DCL emploit un "lock" (mutex) pour justement rendre cohérent l'accès au GetInstance ().
N'y a-t-il pas une incohérence dans le fait d'employer un lock pour chaque appel à GetInstance () ?
Pourrais-tu m'aider à mieux comprendre ?
Merci
Le DCL suppose que
- l'ecriture d'un pointeur est atomique (autrement dit on va lire
ou bien l'ancienne valeur -- nulle -- ou la nouvelle, pas un
melange des deux);
- si le pointeur vers le singleton n'est pas nul, la valeur pointee
est correcte (et donc avec cet anti-idiome il n'y a pas de
synchronisation dans ce cas la). Or les methodes de coherence de
cache ne garantissent generalement rien sur l'ordre dans lequel
sont visibles sur un autre processeur des ecritures a des
adresses differentes. (Ils garantissent que tous les processeurs
partageant une adresse verront les ecritures a cette adresse dans
le meme ordre).
Seules les methodes de synchronisation fortes peuvent resoudre le
premier probleme.
Le deuxieme peut l'etre aussi en mettant dans la branche else la
barriere memoire qui va bien (voir la liste de celles de ton
processeur, si c'est l'IA64 et que tu comprends toute les nuances,
fais-moi signe, j'ai des questions a te poser :-), c'est moins
couteuse qu'un mutex (qui comprennent une telle instruction).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++...index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org