Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-08-07 at 10:33, Tim Janik wrote:
> 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?

It's not more efficient in the sense of "faster", but in the sense
of "doesn't need to be initialized programmatically, not a separate
malloc'ed block", etc.

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

Double-checked-locking, sorry. See glibconfig.h, configure.in
an many discussions here in the past.

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

No, this isn't true. All of GLib works if you call g_thread_init()
somewhere in the middle. We (Sebastian in particular) spent a lot
of time and energy getting that to work.

That's what all the functions called from g_thread_init_glib (void)
are about.

> it's documented, it should be clear to anyone using threads --- i see
> no point coding around it.

It's not documented that I can see (which is good...) I don't see
it anywhere in:
 
 http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html
 
Regards,
					Owen