Re: work around for circular reference retain count limitation?
Re: work around for circular reference retain count limitation?
- Subject: Re: work around for circular reference retain count limitation?
- From: publiclook <email@hidden>
- Date: Wed, 9 Apr 2003 18:59:50 -0400
Circular references are a common problem with retain count systems.
Many common or popular data structures use or require circular
references. Even such common data structures and the AppKit view
hierarchy (a tree) have the potential for retain cycles if they were
not avoided by convention.
The convention used for view is tied to the idea of object ownership. I
think Apple's online documentation describes this concept. Basically,
by convention, each view "owns" its sub-views, but no view owns its
super-view. Combine that convention with the requirement that a single
view can only be in one hierarchy at a time and can not be referenced
multiple times even within one hierarchy and you no longer have danger
of retain cycles in the view hierarchy.
Another convention that is popular is to decouple objects so that they
don't retain each other. This is used with NSNotificationCenter which
does NOT retain the objects that subscribe for notifications.
Subscribed objects are required to explicitly unsubscribe when they are
deallocated or the notification center will be left to a pointer to a
deallocated object. Keep in mind that not all object relationships need
to have any impact of reference counts and that it is always a good
idea to de-couple objects. One object retaining another indicates a
very intimate relationship between the objects. In most cases, that
intimacy in not needed and should be avoided for many reasons.
You imply in your post that you find using conventions that avoid
reference cycles and designing systems to avoid retain cycles "clumsy".
I think it is more clumsy to invasively search the heap for stored
values that might be pointers, thrash the processor cache, cause
needless paging, and still miss lots of dependencies. That is what
happens when conservative mark/sweep garbage collectors are use with C.
One alternative to clumsy C garbage collectors is to not use C. Java
and Smalltalk are both wonderful languages with clean garbage
collectors, but neither interoperates well with the billions of lines
of tested and useful C code in the world. Objective-C is a compromise
that sacrifices features in some areas in favor of the ability to
program to the metal and easily use all of the C code in the world.
You wrote "Suppose two instances with life-times that are totally
independent of each other." If they have totally independent
lifetimes, why do they retain each other ? Instead, when one object is
deallocated, have it explicitly remove references to itself from other
objects (just like it removes itself from notification centers). Have
I solved your problem ?
On Wednesday, April 9, 2003, at 04:53 PM, Wesley Tam wrote:
Hello,
Recently we have been developed an architecture of objects where, in
the simplest case, a bidirectional aggregate relation can exist between
two objects. Note that the life-times of the two objects are totally
independent of each other.
I am currently looking for a good workaround to the circular reference
retain count limitation. I've illustrated a simple case of the problem
for clarity, additionally the relationship between the the two objects
is an aggregation as opposed to a composite:
Suppose two instances with life-times that are totally independent of
each other. At some point in time Object A references Object B, and
Object B references object A. This creates a circular references
between the two objects. The reference count of each instance is
incremented and because of this, they can never be released (i guess
this is kind of like deadlock where each object is waiting for the
other release before itself will).
Now this illustrates the limitation of the retain-count memory
management system. In the past, i've just carefully, and selectively
delegated the retains that are called when these binding is created,
but i find this a bit of a clumsy solution and it doesn't scale up to
when you have an object that has many bidirectional links; it makes
code difficult to maintain as well. I've also looked at creating a
'destroy' method that would remove any bidirectional links with the
object that is being deleted, before calling release, (but there are
some obvious problems with this solution; in essence this is a explicit
destructor call so some object would have to be given responsibility
for this task). I've also looked at storing handles to objects as
opposed to storing the actual pointer, With this solution the object
would have to look up the adjacent object from some Singleton that
consisted of a list of possible objects, but this solution seems kind
of clumsy as well and can be a bit slow with large sets of objects.
I've briefly looked at Ken Case Weak Link solution at:
http://www.cocoadev.com/index.pl?WeakReferences (what do you think of
his approach?) and one at
http://h-world.simugraph.com/docs/refcount.html (I'm not fond of this
solution).
I'm curious as to the best way to address this problem, drawbacks, and
if there is a clean and scalable solution that can be relatively easy
to integrate. Any help or suggestions would be greatly appreciated;
Thanks for your help and insight.
Wesley T. | Software Developer | NOITAMINANIMATION |
www.noitaminanimation.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.