Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-08-07 at 04:52, Tim Janik wrote:
> On 6 Aug 2003, Owen Taylor wrote:
> 
> > * For normal mutexes, static mutexes are more efficient than
> >   dynamically allocated mutexes and a lot easier to manage.
> >   That's why we use them in most places in GLib for locking
> >   global resources.
> 
> how can static mutexes be more efficient if:
>   #define g_static_mutex_lock(mutex) \
>       g_mutex_lock (g_static_mutex_get_mutex (mutex))
> their implementation is based on normal dynamic mutex functions?

If you poke around a bit more, you'll see that in the normal
case the g_static_mutex_get_mutex (mutex) macro ends up expanding
(GMutex*) &((mutex)->static_mutex).

> for some configurations, g_static_mutex_get_mutex() may even go through
> a single glib-global lock used to protect all static mutexes.

This is distinctly the unusual case; in order for a function,
much less a lock, to be needed in the normal case:

 A) A vtable has to have been passed to g_thread_init()
 B) Double-checked doesn't work on the platform

> as for being easier to manage, that boils down to:
>   G_LOCK_DEFINE_STATIC (type_lock);
> vs:
>   static GMutex *type_lock;
>   init { type_lock = g_mutex_new (); }
> which is no problem if you have an init function, here, g_type_init().

The problem is that g_mutex_new() is basically a no-op before
g_thread_init(), so if g_type_init() is called prior to g_thread_init(),
then things don't work. Static mutexes are designed to work fine
both before and after g_thread_init() without extra intervention.

Regards,
					Owen