Re: Atomic Reference Counts in GObject

[Tim Janik <timj gtk org>]

On Wed, 27 Apr 2005, Owen Taylor wrote:

> On Wed, 2005-04-27 at 10:05 +0200, Jonas Bonn wrote:
> > > There's a bug open about using g_atomic_* stuff for GObjects though:
> > >
> > >  http://bugzilla.gnome.org/show_bug.cgi?id=166020
> >
> > Thanks.  That's what I was looking for.
> > Looking at the patches, though, I still end up scratching my head over one bit:
> >
> > if (g_atomic_int_get (&object->ref_count) == 1)
> >      G_OBJECT_GET_CLASS (object)->dispose (object);
> >
> > Why run dispose with the reference count at 1?  It seems to be that it
> > would make more sense to drop the reference count to 0 (atomically)
> > and then run dispose.  That way you ensure that the object is not
> > picked up again half-way through the dispose method where it's not
> > necessarily getting a coherent instance anymore.
>
> Dispose methods are allowed to resurrect objects. One g_object_unref()
> has been called on an object with a refcount of 1, there are no
> *external* references to the object by definition ... no other
> thread can hold a reference to the object, or the refcount would be 2.

this is also assumed by the patch currently in bugzilla, but this assumption
is wrong. other threads may hold weak references to the object (not
neccessarily a weak_ref though, object pointers can be cleaned up by many
means, e.g. through a ::destroy connection). 
and because of that, they may also "resurrect" the object at any time by
incrementing its reference count. this is the reason why ref_count may not
be temporarily set to 0 before all external ref_counts have actually been
unref-ed.

> Regards,
> 					Owen

---
ciaoTJ