Thread-safe initialization of function-local static const objects
Posted
by sbi
on Stack Overflow
See other posts from Stack Overflow
or by sbi
Published on 2010-06-02T08:04:00Z
Indexed on
2010/06/02
8:23 UTC
Read the original article
Hit count: 328
This question made me question a practice I had been following for years.
For thread-safe initialization of function-local static const objects I protect the actual construction of the object, but not the initialization of the function-local reference referring to it. Something like this:
namspace {
const some_type& create_const_thingy()
{
lock my_lock(some_mutex);
static const some_type the_const_thingy;
return the_const_thingy;
}
}
void use_const_thingy()
{
static const some_type& the_const_thingy = create_const_thingy();
// use the_const_thingy
}
The idea is that locking takes time, and if the reference is overwritten by several threads, it won't matter.
I'd be interested if this is
- safe enough in practice?
- safe according to The Rules? (I know, the current standard doesn't even know what "concurrency" is, but what about trampling over an already initialized reference? And do other standards, like POSIX, have something to say that's relevant to this?)
For the inquiring minds:
Many such function-local static const objects I used are maps which are initialized from const arrays upon first use and used for lookup. For example, I have a few XML parsers where tag name strings are mapped to enum
values, so I could later switch
over the tags enum
values.
© Stack Overflow or respective owner