Re: ICU4C Initialization

From: "Robert Buck" <[email protected]>
> To me this part of the proposal (Section 5, Part B) implies
> the use of double checked locking, and possibly in combination
> with the singleton design pattern. So it still introduces at
> least one static initializer for the lock to guard the internal
> singleton state, namely the pointer to the initialization object/functor.

Yes, a singleton ICU global mutex, but no C++ static initializers.  I don't
want them either.

I found no platform independent solution, but separate Windows and Posix
approaches that cover the problem of initializing the first mutex, the ICU
global mutex.

On POSIX platforms, a pthread mutex can be initialized with the value
PTHREAD_MUTEX_INITIALIZER.  This is a plain C initialization, not a C++
static init, and mutexes that are initialized in this way are ready for use.
Nothing additional needs to be done to prepare the mutex before spinning up
threads and banging on it.

On Windows, a double-checked lock is necessary to get the ICU global mutex
set up.  The InterlockedCompareExchangePointer() function on Windows will
safely do the double-checked lock, including all the any required memory
fencing on platforms where it matters.  InterlockedCompareExchange has been
around since Windows 95, which ought to be far enough back.

A portable initialization would be nicer, but the mutex implementation is
already ifdefed up for Windows vs. POSIX, and this really doesn't make
things worse.

  -- Andy Heninger
     [email protected]