ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix insideous problem with mutex initialisation

Browse source 
explanation: we use pthread_once to define a mutex type descriptor,
used to define some of our mutexes as recursive mutexes. Now,
pthread_once relies on a counter stored in a given location;
we used a non-exported global var for this counter.

Unfortunately this ties the mutex initialisation to the static
initialisation of the compilation unit holding this counter variable.
Theoretically it would be possible (we never observed such an incident)
that, during static initialisation, a singleton was brought up,
which requires a class-scoped lock, implemented as recursive mutex.
And it would be possible for this singleton locking to happen prior
to initialisation of the mentioned counter variable.

As a fix, I've moved the counter varialbe into a function scoped
static variable, since that is guaranteed by the C++ runtime system
to be initialised at first usage of the function, irrespective of the
initialisation order of the enclosing compilation units
This commit is contained in:
Fischlurch 2013-10-13 01:48:27 +02:00
parent 2b437b49ad
commit 08cae2617d
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
src/lib/sync.cpp
View file

@ -37,7 +37,6 @@ namespace sync {
namespace { // private pthread attributes
pthread_mutexattr_t attribute_;
pthread_once_t is_init_ = PTHREAD_ONCE_INIT;
void
initAttribute()
@ -50,7 +49,8 @@ namespace sync {
inline pthread_mutexattr_t*
recursive_flag()
{
pthread_once (&is_init_, initAttribute);
static pthread_once_t _is_init_sync_mutex_attribute_(PTHREAD_ONCE_INIT);
pthread_once (&_is_init_sync_mutex_attribute_, initAttribute);
return &attribute_;
}
}