Re: GObject thread safety

[Tim Janik <timj gtk org>]

On Thu, 1 Nov 2001, Michael Meeks wrote:

> 
> Hi Tim,
> 
> 	Just reading through gobject.c I was wondering, what attempt
> if any is there to ensure correct tracking of object->ref_count ? eg.
> g_object_unref seems to make no effort to ensure that the ref count is
> consistant with any other threads performing the operation at the same
> time.
> 
> 	I mean - I can see a performance case for it; but, it seems to
> me that g_object_ref / unref not being thread safe implies that an
> object can only possibly be 'used' - properties set / got, signals
> emitted (g_object_set_value) etc. from a single thread.

right, a single object can only be used in one thread at a time.
that's the reason we have a gdk/gtk wide global lock. you need to aquire it
before you access any gdk/gtk objects.
the same holds for other objects people are using, say you derive a bunch
of objects from GObject to implement your model, then you need to make sure
to have and hold a model lock before you access any of those.

> 	Is it then the case that only the type system is thread safe ?

GObject isn't thread-unsafe, it just uses the normal glib locking convention,
of the user having to pay attention to lock hist structs before using them.
that can't be done for the type system of course, so we do fine grained locking
there.

> 	Oh - and the type system locking still shows as the most
> significant thing on my (UI handler) profile, it would be good to be
> able to propagate lifecycle invariants from instance to type to avoid
> needing to do so much locking. Alex' patch does this well - can we
> expect to see that soon ?

originally yes, but then interface extensions popped up (recent mail from
me on that on gtk-devel) so i'll prolly commit interface initializations
before hand, and then again adapt my alex-based patch ;)

> 
> 	Regards,
> 
> 		Michael.

---
ciaoTJ