Re: Confused about a thread-safe singleton example.
On Dec 6, 1:12 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:0054bdcc-455a-4f37-b06c-3708ea72b0eb@s9g2000prm.googlegroups.com...
On Dec 5, 10:32 am, "Chris M. Thomasson" <n...@spam.invalid>
wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
[...]
I did (on a Sun Sparc, under Solaris). It's true that you
need the fences, and that they do increase execution time,
but they're unavoidable in any working solution anyway.
There not unavoidable for certain lock implementations
(asymmetric Dekker algorithm for one):
http://groups.google.com/group/comp.programming.threads/browse_frm/th.=
...
See?
No. I don't see. Some sort of fences or membar instructions
are certainly necessary if you expect the other threads to see
your writes.
Na. Everything is taken care of by `pthread_once()'.
Which has the fences or whatever in it.
(The code you posted is NOT thread safe, and will not work
on any number of architectures, including Sparc, Alpha,
Itanium...)
The pseudo-code I posted is thread-safe. It uses POSIX Thread
`pthread_once()' for the initialization of the Meyers singleton.
`pthread_once()' synchronizes the memory.
Except that there were control flows which used the variables
without going through pthread_once:
static T* instance() {
if (! g_tls) {
pthread_once(&g_once, g_init);
g_tls = g_obj;
assert(g_tls);
}
return g_tls;
}
All you've done is replace the scoped mutex lock in double
checked locking with pthread_once; that doesn't solve
anything. If a thread sees g_tls non-null, there's no
guarantee that it will see a fully constructed object.
No. Did you notice that g_tls exists in TSD? Notice the
`__thread' decoration in front of the `g_tls' variable:
No. What's __thread? I can't find it, either in Posix nor in
C++. (Looks like a Microsoft'ism to me, but that can't be the
case with pthread_once.)
OK, I know that you can make double checked locking work using
thread local storage, acquiring the lock the first time you
enter the function in each thread. Depending on the
implementation of thread local storage, that's likely to be more
expensive than just acquiring the lock. (I've not used thread
local storage recently, so I can't say, but I know that some
early implementations were nothing more than basically a map,
indexed by the thread id, and protected by a mutex.)
In the end, from an engineering standpoint, there are really
only two (or two and a half:-)) valid solutions:
T&
Singleton::instance()
{
ScopedLock l( ourMutex ) ;
if ( ourInstance == NULL ) {
ourInstance = new Singleton ;
}
return *ourInstance ;
}
and
T&
Singleton::instance()
{
if ( ourInstance == NULL ) {
ourInstance = new Singleton ;
}
return *ourInstance ;
}
with documentation stating that the instance function must be
called before multithreading is started. (The half, above, is
that in most such cases, I'll add code to ensure that instance
is called from a static initializer, so instance is guaranteed
to be called during static initialization.)
Of course, if the Singleton is mutable, the client needs a lock
to access it, and it is fairly simple, using smart pointers, to
use the same lock for the test and for accessing the instance.
template<typename T>
class once {
__thread T* g_tls;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which doesn't compile with my (Posix compliant) compiler.
[...]
The only caveats for this pseudo-code would be all the rules
that pertain to Meyers singleton object destructors... Cannot
access a singleton from a dtor of a singleton.
That's because you insist on destructing the singleton. I never
do.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34