Re: Is this safe?
On Jul 1, 12:55 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
Is this safe?
Not in the slightest.
Didn't think so hence the post.
See "C++ and the Perils of Double Checked
Locking"http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
for a thorough description of why the above does not work and has
never worked.
Very interesting article, I have seen double checked locking patterns
discussed in AAs book modern C++ design. Interesting to read this.
See the C++ FAQ on the Static Initialization Order
Fiasco.http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12
Declaring a mutex like that may be a bad idea.
Also, after reading the FAQ, do not declare a mutex like:
T* foo()
{ static mutex m;
}
or like
T* foo()
{ static mutex * m = new mutex;
}
Doing so introduces a race condition on the construction of the mutex;
this does not guarantee a single creation of the mutex itself. (It
does not guarantee a single call to the underlying mutex init system
call, ex: pthread_mutex_init.)
Also, it gets even worse. You have static data members of template
classes. It doesn't work the way you want it to work. You have to
define static data members in a single translation unit (read: cpp
file). You cannot declare them in the header file, and you definitely
cannot have "static" in "template<typename T> static Singleton<T>*
Singleton<T>::instance_ = 0;". However, you also simply cannot define
the static data member in a cpp file because the compiler will only
instantiate the definition on demand, when the template has been
instantiated, which probably occurs in other translation units. (When
people really need to do this, they generally have a single cpp file
whch contains a template instantiation for every argument to the
template used in the entire program.)
I thought this was the case and this was my primary concern.
Usage follows the following form for example...
class A
{
friend class Singleton<A>;
public:
int a;
};
... where the singleton class is intended to give class A singleton
functionality. Singleton objects are then accessed as you'd expect...
A::instance().a = 10;
I don't even understand what's going on here. A friend class
declaration merely provides access so Singleton<A> may access A's
protected and private members. It has absolutely nothing to do with A
taking implemention from Singleton<A>. How does that compile? What's
going on here? There is no function instance in the class A.
My mistake, omitted a couple of lines. Should be...
template< class T >
class singleton
{
....
};
class A
{
friend class Singleton<A>;
public:
static A& instance()
{ return SIngleton<A>::instance(); }
int a;
};
This all seems to work fine up to a point. What concerns me is that I
can see no specific declarations of instance pointers or critical
section keys for any of the singleton classes in use (and there are
several), beyond these lines in the header file...
template<typename T>
static Singleton<T>* Singleton<T>::instance_ = 0;
template<typename T>
CriticalSection PhoenixSingleton<T>::key_;
Is this safe?
It shouldn't even compile. Seehttp://www.comeaucomputing.com/tryitout/
Also the static initialization order fiasco may be a problem if
someone calls singleton get before main.
Erm, can't comment on that, unless I have missed some details in this
example then it does compile using vs2008. However I see that when I
take the original example with the corrections and try it out on
comeau then it does indeed fail.
See the C++ FAQ on why you should not free singletons without a
compelling reason to do so. If the singleton is just memory, and
you're running on any sort of non-ancient OS which will reclaim memory
when the process dies (read: basically anything nowadays, win XP,
linux, mac, etc.), then you will not leak by not destroying the
singleton explicitly, and you avoid the static de-initialization order
fiasco.
Can you clarify where? I have searched the FAQ and find no references
to singletons. Are you still refering to the FAQ lite? I am
interested in this becase the code also contains another, non-meyers,
singleton implementation which uses a clunky singleton_destructor
object to hold references to and destory created singletons in a LIFO
order on termination, which is also causing crashes on exit.
Here's an example of how to do a singleton correctly. It avoids
acquiring a mutex on every get call. It has a specific restriction to
its interface that the singleton should not be accessed concurrently
before main(). (If you really need that, you would need more
expressive power than mutexes and the C++ standard. You would need
something like pthread_once which isn't available on all systems.)
Note that the example only provides a single, thread-safe
initialization of the singleton. If the singleton has data read and
writable by several threads, that will require a (not static) member
mutex to protect that data.
//from your threading abstraction header
class mutex_t;
class guard_t { public: guard_t(mutex_t& ); ~guard_t(); private:
mutex_t& m; };
//hpp file
class singleton_t
{
public:
static singleton_t & get();
//insert your public interface here.
private:
singleton_t(){}
singleton_t(singleton_t const& );
singleton_t& operator= (singleton_t );
~singleton_t();
//insert your data members here.
};
//cpp file, implementation file for singleton_t
singleton_t& singleton_t::get()
{ /* Initialization of POD with const expressions happens before
runtime.
Also, could leave out the "= 0" as all POD are zero initialized
before runtime.
*/
static singleton_t * t = 0;
if (0 == t)
t = new singleton_t;
return *t;
}
bool force_init_before_main = (singleton_t::get(), true);
Clearly the intention of the original design was to produce a reusable
class which could be used to infer singleton functionality on classes
which utilised it. This is still desirable in the solution. Can I
use a variation of your example above as a base class and derive
objects from it?
eg.
class singleton_base
{
public:
static singleton_t & get();
protected:
singleton_t(){}
~singleton_t(){}
private:
singleton_t(singleton_t const& );
singleton_t& operator= (singleton_t );
~singleton_t();
};
class derived_singleton : public singleton_base
{
public:
// public interface here...
private:
derived_singleton(){}
derived_singleton( const derived_singleton& );
derived_singleton& operator=( const derived_singleton& );
~derived_singleton(){}
// data members here
};
I notice from some experiments with the example that if the singleton
header and .cpp file are both compiled into a library, that the
force_init_before_main assignment is not executed which will stop the
singleton creation being thread safe again. Why is that? Is it
enough to move this to a transation unit directly compiled into my
mainline code rather than a lib?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]