Re: instance-private-data issue

[Tim Janik <timj gtk org>]

On 7 Aug 2003, Owen Taylor wrote:

> 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).

i'm aware of that which is why i wrote "for some configurations" below.
the question is, how can a static mutex be more efficient than
a dynamic mutex if under best circumstances it turns into calling
dynamic mutex functions?

> > 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

what do you mean with "Double-checked"?

> > 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.

huh? i have zero tolerance for people calling glib functions before
g_thread_init(). we've been saying that for years, things simply
don't work if you do that (since even g_malloc() which is used by
most glib functions needs g_thread_init() be called beforehand if
at all).
it's documented, it should be clear to anyone using threads --- i see
no point coding around it.

> Regards,
> 					Owen
>

---
ciaoTJ