[reSIProcate] unsafe static Mutex object initialization

[Aron Rosenberg]

The best way to handle this is actually to make the mutex be a static
pointer which gets allocated during a class constructor. See ThreadIf class
and mTlsDestructorsMutex and friends for the best way to implement this.

-Aron

Aron Rosenberg
LifeSize, a division of Logitech


On Thu, Jul 21, 2011 at 11:25 AM, Daniel Pocock <
daniel at readytechnology.co.uk> wrote:

>
>
>
> 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?
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110721/fb6a8f87/attachment.htm>