Re: Confused about a thread-safe singleton example.
"James Kanze" <james.kanze@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()'.
(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:
template<typename T>
class once {
__thread T* g_tls;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
static T* g_obj;
static pthread_once_t g_once;
[...]
Here is how it works:
static T* instance() {
1: if (! g_tls) {
2: pthread_once(&g_once, g_init);
3: g_tls = g_obj;
4: assert(g_tls);
}
5: return g_tls;
}
1. If calling threads local pointer, `g_tls', is NULL, that means its the
first time the calling thread has ever accessed the singleton. Therefore, it
needs to funnel itself through `pthread_once()' in order to properly
synchronize with the static initialization. If calling threads local pointer
in not NULL, goto step 5...
2. First time threads go though synchronization point!
3. First time threads set their local pointer to the _fully_ visible global
pointer and the object it points to will also be visible; thanks to
`pthread_once()'...
4. Make sure the static initialization worked.
5. Return calling threads local instance pointer.
The fast-path occurs when a thread calls the singleton more than once; the
slow-path is thread first use which in turn sets its thread local pointer to
instance. Second use (the fast-path) goes directly to the local pointer and
skips the call into `pthread_once()'. Each thread call `pthread_once()'
exactly ONE time per singleton type. The thread-local pointer ensures that a
thread only ever makes one call to `pthread_once()'. Examine the code
again...
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.