Re: Atomic Reference Counts in GObject



On Wed, 2005-04-27 at 17:16 +0200, Jonas Bonn wrote:
> > 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.
> 
> Unless there are weak references to the object... while the dispose
> method is running, I can still grab a reference to the object in
> another thread through the weak references I have.  If the dispose
> method is meanwhile busy dismantling the object, I will get an object
> that's no longer coherent... I'd have to add checks everywhere to make
> sure that all the references held by the (possibly half-disposed)
> object are still valid before I use them.
> Drop the reference count to 0 and calling g_object_ref on the weak
> reference will fail... obviously, I know the weak reference is no
> longer valid and that the notifier will be called shortly.
> Or call the weak notifiers before disposing the object so that I know
> to remove the weak reference from my list and to not even bother to
> try to reference it.

The only way this would be better is if we added something like
a g_weak_reference_try_reference() that was guaranteed to either fail
or succeed atomically... 

 if (weak_pointer && weak_pointer->ref_count != 0)

is *not* legitimate because the weak_pointer could be cleared between
the two checks... I suppose you could put a global lock around all
your weak pointers and get it from your weak reference callback,
but that's pretty ugly.

But the fact that dispose() (and that includes ::destroy callbacks
from GtkWidget) are allowed to resurrect means that the earliest point
we could possibly present such a guarantee is when we clear weak
references in g_object_real_dispose()

If you want to access your object from multiple threads, you really
can't get around having a 'destroyed' flag and locking.

Remember dispose() is not a finalizer ... that's separate.... once
the object is being finalized, all weak refs are already gone.

Regards,
						Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]