From 08cae2617d9b659e73737f22bf6f07817414fa53 Mon Sep 17 00:00:00 2001
From: Ichthyostega <prg@ichthyostega.de>
Date: Sun, 13 Oct 2013 01:48:27 +0200
Subject: [PATCH] fix insideous problem with mutex initialisation

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
---
 src/lib/sync.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lib/sync.cpp b/src/lib/sync.cpp
index 902652de5..590932906 100644
--- a/src/lib/sync.cpp
+++ b/src/lib/sync.cpp
@@ -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_;
     }
   }