Forcing something to be destructed last in C++

Question

I am working on a C++ app which internally has some controller objects that are created and destroyed regularly (using new). It is necessary that these controllers register themselves with another object (let's call it controllerSupervisor), and unregister themselves when they are destructed.

The problem I am now facing is happening when I quit the application: as order of destruction is not deterministic, it so happens that the single controllerSupervisor instance is destructed prior to (some) of the controllers themselves, and when they call the unregister method in their destructor, they do so upon an already destructed object.

The only idea I came up with so far (having a big cold, so this may not mean much) is not having the controllerSupervisor as a global variable on the stack, but rather on the heap (i.e. using new). However in that case I do not have a place to delete it (this is all in a 3rd party kind of library).

Any hints/suggestions on what possible options are would be appreciated.

Answer 1

The order of destruction of automatic variables (that include "normal" local variables that you use in functions) is in the reverse order of their creation. So place the controllerSupervisor at the top.

Order of destruction of globals is also in the reverse of their creation, which in turn depends on the order in which they are defined: Later defined objects are created later. But beware: Objects defined in different .cpp files (translation units) are not guaranteed to created in any defined order.

I think you should consider using it how Mike recommended:

1. Creation is done by using the singleton pattern (since initialization order of objects in different translation units are not defined) on first use, by returning a pointer to a function-static supervisor object.
2. The supervisor is normally destructed (using the rules about destruction of statics in functions). controllers deregister using a static function of the supervisor. That one checks whether the supervisor is already destructed (checking a pointer for != 0). If it is, then nothing is done. Otherwise the supervisor is notified.

Since i imagine there could be a supervisor without a controller being connected (and if only temporary), a smart pointer could not be used to destruct the supervisor automatically.

Answer 2

You could use the Observer pattern. A Controller communicates to it's supervisor that it's being destroyed. And the Supervisor communicates the same to it's child upon destruction.

Take a look at http://en.wikipedia.org/wiki/Observer_pattern

Answer 3

You could do any of the following according to the circumstances.

1. Use the Observer pattern as suggested by gurin. Basically the supervisor informs the controllers that it is going down...
2. Have the Supervisor "own" the Controllers and be responsible for their destruction when it goes down.
3. Keep the Controllers in shared_pointers so whoever goes down last will do the real destruction.
4. Manage both the (smart pointers to the ) controllers and the supervisor on the stack which will allow you to determine the order of destruction
5. others ...

Answer 4

You could look at using the number of registered controllers as sentinel for actual deletion.

The delete call is then just a request and you have to wait until the controllers deregister.

As mentioned this is one use of the observer pattern.

class Supervisor {
public:
    Supervisor() : inDeleteMode_(false) {}

    void deleteWhenDone() {
     inDeleteMode_ = true;
     if( controllers_.empty()){
      delete this;
     }
    }

    void deregister(Controller* controller) {
     controllers_.erase(
      remove(controllers_.begin(), 
                        controllers_.end(), 
                        controller));
     if( inDeleteMode_ && controllers_.empty()){
      delete this;
     }
    }


private:

    ~Supervisor() {}
    bool inDeleteMode_;
    vector<Controllers*> controllers_;
};

Supervisor* supervisor = Supervisor();
...
supervisor->deleteWhenDone();

Answer 5

It's not exactly elegant, but you could do something like this:

struct ControllerCoordinator {
    Supervisor supervisor;
    set<Controller *> controllers;

    ~ControllerDeallocator() {
        set<Controller *>::iterator i;
        for (i = controllers.begin(); i != controllers.end(); ++i) {
            delete *i;
        }
    }
}

New global:

ControllerCoordinator control;

Everywhere you construct a controller, add control.supervisor.insert(controller). Everywhere you destroy one, add control.erase(controller). You might be able to avoid the control. prefix by adding a global reference to control.supervisor.

The supervisor member of the coordinator won't be destroyed until after the destructor runs, so you're guaranteed that the supervisor will outlive the controllers.

Answer 6

A couple of suggestions:

• make the controllerSupervisor a singleton (or wrap it in a singleton object you create for that purpose) that's accessed via a static method that returns a pointer, then the dtors of the registered objects can call the static accessor (which in the case of the application shutdown and the controllerSupervisor has been destroyed will return NULL) and those objects can avoid calling the de-register method in that case.

• create the controllerSupervisor on the heap using new and use something like boost::shared_ptr<> to manage its lifetime. Hand out the shared_ptr<> in the singleton's static accessor method.

Answer 7

Make the cotrol supervisor a singelton. Make sure that a control constructor gets the supervisor during construction (not afterwords). This guarantees that the control supervisor is fully constructed before the control. Thuse the destructor will be called before the control supervisor destructor.

class CS
{
    public:
        static CS& getInstance()
        {
            static CS  instance;
            return instance;
        }
        void doregister(C const&);
        void unregister(C const&);
    private:
        CS()
        {  // initialised
        }
        CS(CS const&);              // DO NOT IMPLEMENT
        void operator=(CS const&);  // DO NOT IMPLEMENT
 };

 class C
 {
      public:
          C()
          {
              CS::getInstance().doregister(*this);
          }
          ~C()
          {
              CS::getInstance().unregister(*this);
          }
 };

Answer 8

There is basically a whole chapter on this topic in Alexandrescu's Modern C++ Design (Chaper 6, Singletons). He defines a singleton class which can manage dependencies, even between singletons themselves.

The whole book is highly recommended too BTW.

Answer 9

How about having the supervisor take care of destructing the controllers?

Answer 10

Ok, as suggested elsewhere make the supervisor a singleton (or similarily controlled object, i.e., scoped to a session).

Use the appropriate guards (theading, etc) around singleton if required.

// -- client code --
class ControllerClient {
public:
    ControllerClient() : 
     controller_(NULL)
     {
      controller_ = Controller::create();
     }

    ~ControllerClient() {
     delete controller_;
    }
    Controller* controller_;
};

// -- library code --
class Supervisor {
public: 
    static Supervisor& getIt() {  
     if (!theSupervisor ) {
      theSupervisor = Supervisor();
     }
     return *theSupervisor;
    } 

    void deregister(Controller& controller) {
     remove( controller );
     if( controllers_.empty() ) {
      theSupervisor = NULL;
      delete this;
     }  
    }

private:    
    Supervisor() {} 

    vector<Controller*> controllers_;

    static Supervisor* theSupervisor;
};

class Controller {
public: 
    static Controller* create() {
     return new Controller(Supervisor::getIt()); 
    } 

    ~Controller() {
     supervisor_->deregister(*this);
     supervisor_ = NULL;
    }
private:    
    Controller(Supervisor& supervisor) : 
     supervisor_(&supervisor)
     {}
}

Answer 11

While ugly this might be the simplest method:

just put a try catch around the unregister call. You don't have to change a lot of code and since the app is already shutting down it is not a big deal. (Or are there other ratifications for the order of shutdown?)

Others have pointed out better designs, but this one is simple. (and ugly)

I prefer the observer pattern as well in this case.

Answer 12

GNU gcc/g++ provides non portable attributes for types which are very useful. One of these attributes is init_priority that defines the order in which global objects are constructed and, as a consequence, the reverse order in which they get destructed. From the man:

init_priority (PRIORITY)

 In Standard C++, objects defined at namespace scope are guaranteed
 to be initialized in an order in strict accordance with that of
 their definitions _in a given translation unit_.  No guarantee is
 made for initializations across translation units.  However, GNU
 C++ allows users to control the order of initialization of objects
 defined at namespace scope with the init_priority attribute by
 specifying a relative PRIORITY, a constant integral expression
 currently bounded between 101 and 65535 inclusive.  Lower numbers
 indicate a higher priority.

 In the following example, `A' would normally be created before
 `B', but the `init_priority' attribute has reversed that order:

      Some_Class  A  __attribute__ ((init_priority (2000)));
      Some_Class  B  __attribute__ ((init_priority (543)));

 Note that the particular values of PRIORITY do not matter; only
 their relative ordering.

Answer 13

You may use Events to signal destruction of Controllers

Add WaitForMultipleObjects in destructor of Supervisor which will wait until all controllers are destroyed.

In destructor of controllers you can raised controller Exit event.

You need maintain global array of Exit event handles for each controller.

Answer 14

The C++ standard specifies the order of initialization/destruction when the variables in question all fit in one file ("translation unit"). Anything that spans more than one file becomes non-portable.

I would second the suggestions to have the Supervisor destroy each controller. This is thread safe in the sense that only the Supervisor tells anybody to destroy themselves (nobody destroys themselves on their own), so there is no race condition. You'd also have to avoid any deadlock possibilities (hint: make sure the controllers can destroy themselves once they've been told to without needing anything else from the Supervisor).

---

It's possible to make this thread safe even if the controller needs to be destroyed before the end of the program (that is, if controllers may be short lived) then they (or somebody else).

First, it may not be a race condition to worry about if I decide to destroy myself and microseconds later the Supervisor decides to destroy me and tells me so.

Second, if you are concerned about this race condition you can fix it by, say, requiring that all destruction requests go through Supervisor. I want to destroy myself I either tell the Supervisor to tell me or I register that intent with the Supervisor. If somebody else -- including the Supervisor -- wants me destroyed, they do that through the Supervisor.

Answer 15

when I read the heading to this question I immediately asked myself "If there was a way that any object could ensure that it was destroyed (destructed?) last, then what would happen if two objects adopted that method?"