Re: Thread-safety issue in GObjects

[Lieven van der Heide <lievenvanderheide gmail com>]

> The specific question is, what happens when one thread calls
> g_object_unref() and just while it's being executed the unref() another one
> calls g_object_ref()? Should my application try to avoid this situation
> making all the ref()/unref() operations thread-safe at application level?

I think that the fact that your unref hasn't finished yet when your
second thread tries to call g_object_ref is irrelevant, the thing
that's relevant is that your g_object_unref has at least started. The
moment your last g_object_unref is called, the object should be
considered gone, and all pointers that used to point to it should then
be considered dangling pointers, which shouldn't be used any more.

I think it's very likely that in your case, it might just as well
happen that your second thread's g_object_ref won't start before the
other thread's g_object_unref has finished, in which case you would
just be trying to ref a pointer to a dead object.

The fact that it's done from multiple threads doesn't matter, what
you're doing is still equivalent to the following:

GObject *obj = new_obj();

g_object_unref(obj);

// now the pointer still has it's original value, but the object it
used to point to is gone.

g_object_ref(obj); // Now you'd be trying to revive the object by
creating a new ref, which obviously won't work.

Calling g_object_ref/unref from multiple threads is allowed, without
locking, but you will have to make sure that the reference you're
ref-ing is a valid one. A possible way of making sure that this is the
case is to give each thread it's own reference.

Greets,

Lieven.

On Thu, May 21, 2009 at 5:26 AM, Aleksander Morgado
<gtk-list aleksander es> wrote:
> Hi all,
>
> Small question about GObject management in multi-threaded applications.
>
> I've got a GObject with a "gpointer priv" in the GObject struct, which is
> just a pointer to the private info of the object. That pointer is set to
> NULL when g_object_unref() is called, after the private data has been
> deallocated. What I see is that thread 1 calls g_object_unref() and, it
> seems that meanwhile another thread 2 gets a new reference of it with
> g_object_ref().
>
> GDB shows the following after a segfault:
> (gdb) p *self
> $2 = {parent = {g_type_instance = {g_class = 0x99efd30}, ref_count = 1,
> qdata = 0x0}, priv = 0x0}
>
> What I understand from this is that g_object_unref() was called, as priv is
> NULL, and still then a reference to the object is available.
>
> The specific question is, what happens when one thread calls
> g_object_unref() and just while it's being executed the unref() another one
> calls g_object_ref()? Should my application try to avoid this situation
> making all the ref()/unref() operations thread-safe at application level?
>
> Cheers and thanks,
> -Aleksander
>
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>