Can a singleton use another one in its destructor?

Question

I have two managers (which are singletons):

1. A licenses manager, counting licences tokens when functionalities are used. The destructor of this release all the licences.
2. A Python manager, managing calls to Python from C++, it requires a specific license from the licences manager. The destructor calls the licences manager to finalize the license usage.

I suppose the order of destruction of the singleton is undefined. How can I avoid the mismatch at the destruction of the managers? Is it possible?

This is my typical implementation of a singleton:

class Manager : private boost::noncopyable
{
  private:
    struct singleton_deleter { void operator () (Manager* m) { delete m; } };
    friend struct Manager::singleton_deleter;

  private:
    boost::mutex                singleton_mutex;
    boost::shared_ptr<Manager>  singleton_instance;

  public:
    static Manager&  instance()
    {
      if(!(bool)Manager::singleton_instance)
      {
        boost::mutex::scoped_lock lock(Manager::singleton_mutex);
        if(!(bool)Manager::singleton_instance)
          Manager::singleton_mutex.reset(new Manager, Manager::singleton_deleter());
      }
      return *Manager::singleton_instance;
    }

  private:
    Manager() { this->lic = LicManager::instance().getLicense(); }
    ~Manager() { LicManager::instance().releaseLicense(this->lic); }
};

Answer 1

Note that since the destruction order of static objects in C++ is the reverse of their construction order, you can make the constructor of one singleton first construct the other singleton it depends on as a function-local static object. For example:

LicManager & LicManager::instance() {
    static LicManager licenceManager;
    return licenceManager;
}

Manager & Manager::instance() {
    static Manager manager(LicManager::instance());
    return manager;
}

Another way would be to use a shared_ptr to share ownership of the singleton, enforcing the destruction order. Make instance() return a shared_ptr instead of a reference. In your use case, store the return value of LicManager::instance() (e.g. a shared_ptr<LicManager>) in your Manager object. This forces LicManager to stay alive for the lifetime of Manager, even if the respective LicManager shared pointer in the global scope is destroyed.

Edit: As pointed out in the comments, yet another solution would be to have only one super singleton which owns all the others and controls the initialization/destruction order.

Answer 2

Store the singleton instance as a static local variable of the accessor function that returns a reference to it. In other words, use the Construct On First Use Idiom.

Then call the accessor function of singleton A, from the constructor of singleton B. This ensures that, the singleton A is constructed before B, which in turn ensures that A is destroyed after B.

There is a variation of this pattern which is to use - instead of a function local static object - a function local static raw pointer to a dynamic object, which is leaked on termination. That approach does not need the constructor of a singleton to call the accessor of another, but of course memory analysers will complain. The idea is that that the singleton is never destroyed, so you are free to depend on it in the destructors of other static objects.

Is it really a so restrictive pattern than you can not have two different classes implemented as singletons ??? If it's true, singleton looks like a useless pattern...

Singleton is a very restrictive pattern, and some might argue that it is useless. But it is not true that you couldn't have two different singleton classes.