Reputation: 3605
I have recently read Andrei Alexandrescu's Modern C++ Design. After reading 6. chapter, I begin to worry about our singletons at company. Since our experienced team leader writes core helper libraries like singletons etc... . I asked him if the way he handles singleton takes care of on dead reference problem ? If he used at_exit function call which is given by C core language?
He told me C++11 has singleton support and will execute CTORs and DTORs in a row that they will not be any dead reference problem. User will not have to cope with synchronization.
Even it sounds awesome I couldn't find any information which confirms him on internet. So please tell me if C++11 takes care of Dead Reference Problem for singletons and if so please explain a little what dark magic going behind ?
Upvotes: 1
Views: 213
Reputation: 40643
Presumably your team leader is talking about singletons implemented as follows:
T &get_value() {
static T val;
return val;
}
In this case, the standard gives two guarantees. The first is that the val
objects will be constructed exactly once, the first time that the flow of program execution passes the declaration of the local static variable, even if that happens simultaneously on several threads 6.7/4
:
An implementation is permitted to perform early initialization of other block-scope variables with static or thread storage duration under the same conditions that an implementation is permitted to statically initialize a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
Static initialisation is only allowed in the case of constants, so as long as T
does not have a constexpr
constructor you shouldn't have to worry (but read 3.6.2 for the full rules, in case there is some edge case that is relevant to your code).
The second guarantee is that all variables with static storage duration will be destructed in the reverse order of their construction 3.6.3/1
:
Destructors (12.4) for initialized objects (that is, objects whose lifetime (3.8) has begun) with static storage duration are called as a result of returning from main and as a result of calling std::exit (18.5). Destructors for initialized objects with thread storage duration within a given thread are called as a result of returning from the initial function of that thread and as a result of that thread calling std::exit. The completions of the destructors for all initialized objects with thread storage duration within that thread are sequenced before the initiation of the destructors of any object with static storage duration. If the completion of the constructor or dynamic initialization of an object with thread storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first. If the completion of the constructor or dynamic initialization of an object with static storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first. [Note: This definition permits concurrent destruction. — end note ] If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized. For an object of array or class type, all subobjects of that object are destroyed before any block-scope object with static storage duration initialized during the construction of the subobjects is destroyed. If the destruction of an object with static or thread storage duration exits via an exception, std::terminate is called (15.5.1).
While this paragraph gives a lot of scope for concurrent destruction of static objects when their construction was concurrent, the main thing to take away from it is that destruction happens in the reverse order of construction.
Together, these mean means that if T val
depends on some U val
in another of these singleton functions, the U val
will always be constructed before T val
and destructed after the T val
, so overall, this is a safe way of implementing singletons (unless you're doing something very crazy).
Upvotes: 5