safe static destructors when multiple threads call exit()

Question

How do I safely delete static C++ objects in the case when multiple (Posix) threads call exit() in parallel?

It appears in my CentOS6 environment that exit() executes atexit (or on_exit) cleanup handlers by calling something like fct[--cnt]() where cnt is the number of handlers registered. When multiple threads call exit() at the same time, we have a race condition in the unprotected --cnt operation and some handlers may be skipped or called multiple times (leading to the occasional crash). So how can I ensure that just one of the exit() calling threads does the cleanup and all others stop? Note that inserting a pthread_mutex_lock() into a cleanup handler doesn't help because this handler might be skipped...

Unfortunately I can't avoid that multiple threads call exit() because that's code my users will write (I'm providing a library to them).

Looking for safe ideas, thanks!

Answer 1

There is no portable way to handle multiple calls to exit() - because it is undefined (behaviour) what happens in that case.

But, for some particular platform you may find a way to do it. A somewhat generic solution to the "called multiple times" is to have a flag in your static objects like "am I already destructed". As usual, you may hide that in a template:

template <typename T> class StaticExitHandled {
public:
    std::unique_ptr<T> t_;
    ~StaticExitHandled() { t_.release(); }
};

Now just remember to declare all your static objects with this template. That is just the core of it, add bells and whistles as per your taste. Also, instead of std::unique_ptr<> you may use boost::optional<> or some such thing.

I don't think there is a generic solution to "not called at all".

Actually, I would advise against having non-trivial static objects in multi-threaded environment. So, only have static PODs and objects with severely constrained destructors (depending on what is safe to do at this point in your environment - i.e. closing file handles is OK in most environments).