Discussion :

[r0d]

Bonjour,

j'ai du mal à comprendre les problèmes de concurrence posés par le pattern singleton. Par exemple, je ne comprend rien à ce papier: http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

Ne suffit-il pas de protéger l'accesseur à l'instance unique pour que notre singleton soit thread safe? Par exemple, le singleton suivant est-il thread safe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
static Singleton* GetInstance()
{
	boost::mutex::scoped_lock lock(my_mutex);
	if ( instance == nullptr )
		intance = new Singleton();
	return instance;
}

[Emmanuel Deloget]

Bonjour,

j'ai du mal à comprendre les problèmes de concurrence posés par le pattern singleton. Par exemple, je ne comprend rien à ce papier: http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

Ne suffit-il pas de protéger l'accesseur à l'instance unique pour que notre singleton soit thread safe? Par exemple, le singleton suivant est-il thread safe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
static Singleton* GetInstance()
{
	boost::mutex::scoped_lock lock(my_mutex);
	if ( instance == nullptr )
		intance = new Singleton();
	return instance;
}

Là, tu protèges la création et l'accès à la ressource, pas son utilisation. Le singleton lui même n'est toujours pas thread safe.

Un singleton thread-safe a un second mutex à l'intérieur du singleton lui-même.

Le papier de Myers dit que ton code est tout à fait valide, cependant la protéction qu'il met en oeuvre est coûteuse. Une fois le singleton créé, il n'y a plus lieu de locker le mutex, parce que - le singleton existant - le même pointeur sera toujours retourné. Du coup, tu va locker pour rien (et un lock, c'est tout sauf gratuit).

Le reste du papier décrit pourquoi il est difficile d'écrire une implémentation valide et complètement correcte de l'instanciation d'un singleton qui ne soit pas diminué par un lock inutile (utilisation du "lock doublement vérifié").

[Luc Hermitte]

Le C++11 va nous permettre d'avoir des singletons thread-safe, robustes et rapides.
La façon la plus simple d'y parvenir, c'est avec le modèle énoncé par Scott Meyers dans son Effective C++ : avec une variable locale statique. Depuis le C++11, ce sera thread-safe.
Par contre, ce singleton là ne permet pas de contrôler finement le moment de sa libération.

En vrac, quelques liens que j'ai collectés sur le sujet. Je n'ai pas encore pris le temps de les trier ni d'évaluer si toutes les solutions données étaient valables.
- http://stackoverflow.com/questions/6...ngleton-in-c11
- http://stackoverflow.com/questions/1...design-pattern
- http://www.athile.net/library/wiki/i...sing_C%2B%2B0x
- http://www.1024cores.net/home/lock-f...initialization
- http://stackoverflow.com/questions/6...singleton-in-c
- http://www.justsoftwaresolutions.co....d-locking.html
- http://silviuardelean.ro/2012/06/05/...on-approaches/

(je te passe les liens qui remettent les singletons à leur place de variable globale vu que ce n'est pas le sujet ici)

[r0d]

Merci Luc

[MicBeastKiller]

Bonjour,
qu'en est-il de ce qui est expliqué ici ?
J'avais eu l'impression (à l'époque où je me suis intéressé à ce design pattern) que les solutions proposées étaient correctes.

[Flob90]

http://come-david.developpez.com/tut...ngleton#L4-a-3

David dit bien qu'en MT c'est complexe. Et à l'époque où il a écrit ca, le C++11 n'existait pas; rendant les solutions au problème assez complexe.