[reSIProcate] unsafe static Mutex object initialization

[Daniel Pocock <daniel@xxxxxxxxxxxxxxxxxxxxx>]

I notice a few places where a Mutex objected is constructed, typically
as a static member of a class:

$ grep Mutex rutil/*.hxx | grep static
Log.hxx:      static Mutex _mutex;
Random.hxx:      static Mutex mMutex;
Time.hxx:                  static Mutex mWrapCounterMutex;
Time.hxx:                  static Mutex mMutex;

The order in which the constructors of these objects are called is
non-deterministic

It is actually possible that an code section depending on the Mutex
could be attempting to lock on the Mutex before the Mutex itself is
initialized



For UNIX, it may be possible to initialize Mutex::mId =
PTHREAD_MUTEX_INITIALIZER, or even define Mutex like so:

#define STATIC_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
typedef pthread_mutex_t Mutex;

and then in some file.cxx:

Mutex mMutex = STATIC_MUTEX_INIT;



However, the situation for Windows is not quite the same:

http://locklessinc.com/articles/pthreads_on_windows/

suggests a hack:

#define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

that depends on the internal structure of the Windows type CRITICAL_SECTION

Has anyone else got any thoughts on this, how it should be done on
Windows, and any other platform considerations that I haven't raised?