singleton thread safe

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:

---

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; }

---

:question:

Citation:

---

Envoy� par 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:

---

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; }

---

:question:

---

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�").

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)

Merci Luc :ccool:

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.

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.