Re: GObject thread safety

[Alex Larsson <alexl redhat com>]

On Fri, 2 Nov 2001, Tim Janik wrote:

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

Otoh, we could add some atomic ops to implement refcounting that is MT 
safe without having the overhead of locking. I've did this for the 
ref/unref in the Mozilla javascript engine, and it makes quite a 
difference (compared to locks).

I do think many people will assume that g_object_ref/unref() can be used 
between threads...

/ Alex