Re: Is this safe?

On Jul 1, 7:38 pm, mattb <matthew.b...@l-3com.com> wrote:


First thing to note: in all libraries, aka all code which isn't "main
()", if you use a namespace member or static class member to implement
exposed functionality, a namespace member of static class member
during its construction in initialization of statics may try to access
your interface, and thus access your namespace member or static class
member. As it stands, 50 50 chance you access your object before its
constructed. Thus, namespace object or static class member which is
prone to this problem should be fixed. It should probably be a
function local static, a singleton if you will, eager initialized or
lazy initialized (see below). (A POD initialized with a const expr is
guaranteed to be done before runtime, and thus cannot be affected by
the static initialized order fiasco.)

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14
The order of destruction may be that a "singleton" is used after it is
destroyed. As the FAQ states, the two simple solutions are
1- Simply "leak" singletons.
2- For all static storage objects A which refer another static storage
object B, ensure that A will call getB in A's constructor,
guaranteeing that B will finish construction before A. The standard
guarantees that static storage objects will be destroyed in opposite
order of creation (just like class members, stack objects, etc.), so
if you follow this practice everywhere, you can safely destroy static
storage objects. (Presumably this guarantee also holds in threaded
environments, though I actually haven't seen any reliable confirmation
of this.)

Alternatively, you can go for the more complex solution(s) which the
FAQ references, on which I am not well equipped to explain. Probably
some single static storage object which registers creation of all
other static storage objects and destroys them in an appropriate
order.


Unfortunately, I don't think that's possible in C++03 as it is
commonly implemented, at least not portably with the portable
threading constructs of mutexes. If you had pthread_once or
equivalent, then maybe.

You can either:

1- Use a function-local static to initialize on demand to solve the
static initialization order fiasco, and then use a namespace member to
eager-initialize it, to guarantee construction before main, and thus
presumably before threads. This requires a global or static class
member, which cannot be done with a template, at least not invisibly
to the end user, for the reasons mentioned above.

2- Or you can use a function-local static to initialize on demand to
solve the static initialization order fiasco, and then lazy-initialize
the singleton to the first required use. However, delaying the
initialization leads to thread safety issues. As mentioned above, you
cannot simply do
     T* get()
     { static mutex_t m;
         //...
     }
because there would then be a race condition on the construction of
the mutex. (At least in C++03. In C++0x, they're "fixing" this to be
threadsafe, meaning you wouldn't even need this mutex, as the
construction of the function local static would be threadsafe
automatically.) You need to construct a mutex earlier to solve this
problem. It cannot simply be a global or a static class member; that's
the static initialization order fiasco again. Thus, to have a lazy-
initialized singleton, you need another singleton, the mutex guarding
it, and that mutex must be an eager-initialized, initialized on-demand
singleton as in 1.

Thus, with just the standard guarantees of the C++03 standard, the
general interpretation of how these guarantees apply to threads, and
mutexes which require a single construction, you cannot do what you
want.

However, as mentioned elsewhere, if you have pthread_once or
equivalent, then I think you could do it, but don't quote me on that.
I don't think (??) windows has an equivalent, though I'd love to be
proven wrong.

Presumably the eager-initialized, initialized-on-demand singleton as
done in my first post would have less overhead than this, as a simple
branch would probably be less expensive than pthread_once on each get
call, but presumably pthread_once is very cheap, probably only a read
barrier for all calls after the first. (Platform specific of course.)

I think that would work, though I recall something about C++ functions
don't have C linkage unless specified extern "C", and thus not being
valid functions for such C interfaces, although I think in practice
everyone ignores this. Or maybe I'm inventing something. Frankly, at
this point I'm over my head. I'd need to review some documents or
defer to experts.

(Disclaimer: the following has not been reviewed or tested.)

//singleton_wrapper.hpp
#include <pthread.h>
#include <cassert>

namespace singleton_wrapper_private_impl
{ template <typename singleton_type>
     singleton_type * & get_pointer()
     { static singleton_type * singleton;
         return singleton;
     }
}

template <typename singleton_type>
void initialize_singleton()
{ singleton_type * & pointer =
singleton_wrapper_private_impl::get_pointer<singleton_type>();
     pointer = new singleton_type;
}

template <typename singleton_type>
singleton_type & singleton_wrapper()
{ //PTHREAD_ONCE_INIT presumably is a const expr,
     //and thus C++03 guarantees this happens before runtime.
     static pthread_once_t init_flag = PTHREAD_ONCE_INIT;

     int x =
         pthread_once(
             &init_flag,
             &initialize_singleton<singleton_type>
        );
     assert(0 == x);
     return *
singleton_wrapper_private_impl::get_pointer<singleton_type>();
}

//someone using singleton_wapper.hpp
#include <iostream>
using namespace std;
class some_singleton_type_X
{
public:
     //insert public interface
private:
     some_singleton_type_X() { cout << "hello world!" << endl; }
     some_singleton_type_X(some_singleton_type_X const& );
     some_singleton_type_X& operator= (some_singleton_type_X );
     ~some_singleton_type_X(){}
     friend void initialize_singleton<some_singleton_type_X>();
};
some_singleton_type_X & get_some_singleton_X()
{ return singleton_wrapper<some_singleton_type_X>();
}

int main()
{ get_some_singleton_X();
     get_some_singleton_X();
}


I'm not sure what's going on here.

First guess: is it a dynamically loaded library, a library opened with
dlopen or equivalent? In which case, the static initialization of the
dll does not occur until dlopen. In which case, it's perfectly fine.
The static initialization of the dll happens before dlopen returns,
and thus happens in a single threaded way. Only once dlopen returns
can the singleton be accessed concurrently, and by that time it has
been safely constructed, including any internal mutexes which guard
internal state. (At least, I presume that dlopen establishes a correct
happens-before relationship.)

Also, unlikely possibility: it might be an allowance in the C++03
standard which is quite troublesome. The standard allows the
initialization of static class members and namespace scope members of
a translation unit to be delayed until something from that translation
unit is referenced. In practice, delaying it to some finite point in
the future is impossible for the compiler, but delaying it
indefinitely, aka optimizing it away, is not impossible. If your
translation unit is never referenced (whatever that means exactly, I
should look at the C++03 standard again), the compiler may optimize
away all static initialization of that translation unit. I recall
hearing on this forum of a real commercial compiler which does, but
nearly all do not do this optimization. It sounds like it was a
minimal attempt to make dlls some degree standard conforming, but
frankly I think it was a really bad thing, as it allows this
completely non-obvious and generally not-wanted "optimization".

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]