détruire un objet singleton

Question

Quelle est la meilleure façon de détruire un objet singleton?

cas A: Environnement fileté simple
cas B: multithread Environnement

Les extraits de l'échantillon (le cas échéant) sera vraiment utile.

[EDIT] Je n'ai pas de cas d'utilisation spécifique J'essaie juste de comprendre que SI TOUT le singleton doit être utilisé, comment le détruire correctement. Si je comprends, à partir des commentaires, il ya 2 scénarios possibles:
1. Détruisez le singleton quand aucun code n'y accède (utilisez des pointeurs intelligents qui se chargeront de détruire l'objet par lui-même en utilisant RAII)
2. Détruire un singleton lors de la sortie du programme indépendamment du fait que du code soit retenu ou non par le singleton. (détruisez explicitement en supprimant l'instance juste avant les sorties principales)

Answer 1

Ne le créez pas en premier lieu! Sérieusement, je vous recommande fortement de reconsidérer votre choix de singleton, en particulier dans un environnement multithread. Au lieu de cela, créez simplement une instance dans main() et transmettez-la dans la hiérarchie des appels où elle est nécessaire.

Vous pouvez utiliser quelque chose comme shared_ptr pour vous assurer que l'objet reste en place jusqu'à ce que plus personne n'en ait besoin.

Answer 2

En multi-thread,

void Singleton::Destroy() 
{ 
    if (instance) { 
     pthread_mutex_lock(&lock); 
     if (instance) { 
      delete instance; 
      instance = 0x0; 
     } 
     pthread_mutex_unlock(&lock); 
    } 
} 

En monothread:

void Singleton::Destroy() 
{ 
    if (instance) { 
     delete instance; 
     instance = 0x0; 
    } 
} 

Answer 3

La réaction contre le dernier de l'utilisation excessive de la décennie de singletons semblent être en bonne santé, bouffi, mais ils ne sont pas tout à fait mal ou injustifié ... la programmation concerne les compromis et la pratique, et il est difficile de généraliser (généralement ;-P). Par tous les moyens revoir la conception et voir si vous pouvez utilement se débarrasser d'eux, mais si non - ainsi soit-il.

De toute façon, si vous voulez comprendre les compromis, vous ne pouvez pas faire mieux que de commencer en lisant Modern C++ Design d'Alexandrescu, qui consacre un chapitre aux alternatives pour Singletons. Fondamentalement, vous posez une question idiote ici parce que nous ne savons pas quelles contraintes opérationnelles vos singleton (s) ont ... quelles interactions potentielles, quelles ressources ils peuvent avoir besoin d'utiliser et s'ils peuvent être rouverts après avoir été fermé etc .. Alors, crachez-le ou se contenter de réponses stupides ;-P.

Answer 4

Laissant de côté la question de savoir si c'est une bonne idée.
Ce que nous devrions faire dans une question séparée!

class S 
{ 
    private: 
     S() {}    // private constructor 
     S(S const&);   // Undefined copy constructor 
     S& operator(S const&) // Undefined assignment operator 

    public: 
     static S& getInstance() 
     { 
      /* 
      * It is guaranteed to be built on first use 
      * and correctly destroyed at the end of the application 
      */ 
      // Need guard for multi-threaded systems (but not on gcc) 
      MULT_THREAD_GUARD; 
      static S theOnlyInstance; 
      return theOnlyInstance; 
     } 
}; 

L'initialisation multi-thread de l'objet est le seul véritable problème. Vous pouvez gérer cela de deux façons.

• Vous pouvez mettre un garde pour vous assurer qu'un seul thread peut entrer dans la méthode getInstance() lorsque vous faites multi-thread builds (IFF vous utilisez gcc ce n'est pas nécessaire car il plante le code requis automatiquement garantie l'objet est seulement initialisé une fois).
• L'autre technique consiste simplement à s'assurer que l'instance est initialisée avant la création de tous les threads. Pour ce faire, appelez getInstance() dans main.Rappelez-vous que si vous faites cela, vous pouvez aussi bien avoir une variable globale que vous détruisez le principal avantage des singletons sur les variables globales (initialisation paresseuse). Non que les variables globales soient bien meilleures que les singletons.

Exemple Garde

// Then in your platform agnostic header file 
#ifndef MULTI_THREAD 
#define MULT_THREAD_GUARD  /* Nothing needed in single threaded code */ 
#else 
#if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 1))) 
#define MULT_THREAD_GUARD  /* Nothing required for GCC 3.2 onwards */ 
#elif defined(YOUR_COMPILERS_MACRO) 
#define MULT_THREAD_GUARD  do { /* Put compiler lock code here */ } while (false) 
#else 
#error "ADD MULTI Thread GUARD for you compiler here" 
#endif 

Answer 5

Si vous allez utiliser une approche globale, je préfère quelque chose comme ceci:

class GlobalThing{ /* ... */ }; 

GlobalThing *global_thing = 0; 

// ... 

int main(){ 
    GlobalThing gt(/* ... */); 
    global_thing = > 

    // create threads 
    // ... 
    // kill threads 
} 

Cela vous donne:

1. Un facilement durée de vie identifiée pour l'objet global.
2. Nettoyage de ressources de la manière typique RAII. Les points ci-dessus signifient qu'il fonctionne dans un environnement multithread sans se soucier des verrous, etc., car aucun thread n'existera avant ou après la durée de vie de gt. Eh bien, dans certains environnements, vous pouvez sortir de main() et d'autres threads continueront à fonctionner, mais c'est une manière terrible d'architecturer votre programme pour diverses raisons.

Qu'est-ce que vous avez encore à vous soucier:

1. pour Initialisation de globals. Mais, contrairement au Static Initialization (and Destruction) Order Fiasco, cette technique vous donne l'avantage de définir l'ordre d'initialisation et de destruction des globaux (si vous les définissez tous de cette manière).
2. Quelque chose d'autre, j'en suis sûr.

Answer 6

Vous pourriez utiliser atexit() si vous ne tenez compte que du nettoyage après des coupures réussies.