|
Boost : |
From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-03-03 10:07:48
I want to initialize a "singleton" type object. To do this, I use
call_once.
void f()
{
call_once(inited, init_singleton);
}
basically. Now, after I init it, I want to use it in some way. So then
I have:
void f()
{
call_once(inited, init_singleton);
use_singleton();
}
Now, I was thinking that call_once may be called in a different thread
already by the time I get to use_singleton, but the singleton has not
been inited yet. So I added a mutex:
void f()
{
call_once(inited, init_singleton);
scoped_lock(singleton_mutex);
use_singleton();
}
init_singleton()
{
scoped_lock(singleton_mutex);
// do initialization
}
(I look at this now and am thinking this only reduces the possible race
condition but may, depending on the implementation of call_once, not
eliminate it entirely). Now I want to call f() in a global variable:
struct some_global
{
some_global() { f(); }
};
some_global a_global;
Now I have a worse condition, in which case the mutex, which is also
global, may be constructed after the global. In this case, during
call_once() in the call to f(), I'd end up waiting on a mutex that
hasn't been constructed inside the scoped_lock. I could use call_once
to initialize the mutex, but I'd have to know what guarantees are made
regarding call_once to know if it solves the problem. Particularly, I
need to know, not only that "flag != once_init" is a postcondition of
call_once, but also that func() has completed execution. So, given that
I still have a race condition in the previous step, and given this issue
of unclear order of global initializations, how would it be best to
solve this problem, or does call_once indeed guarantee this
postcondition ("func() has executed at least one time.")?
Btw, this may be the time to point out that the docs at
http://www.boost.org/libs/thread/doc/call_once.html specify a const
once_flag once_init, whereas the actual thing to document is: const
once_flag BOOST_ONCE_INIT;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk