Re: Thread-safe reference counts.
On Apr 1, 5:58 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
On Mar 31, 4:16 am, "Chris Thomasson" <cris...@comcast.net> wrote:
My only point is that, IMVHO of course, GC can be a wonderful
tool for all sorts of lifetime management schemes. This due to
the fact that it can inform the management protocol when an
object is in a quiescent state.
But you still haven't explained what you mean by "an object in a
quiescent state". All garbage collection can possibly tell you
is whether the object can be (might be) accessed. As far as I
can see, this has nothing to do with the state of the object.
IMO, lifetime management "basically implies" that an object
will only be destroyed when its unreachable;
For what meaning of "destroyed". I intentially chose the word
"terminated" in my discussion to avoid any link with the C++
destructors or delete; those are the usual ways of terminating
an object in C++, but the concept of termination is a design
concept, applicable to all languages, and delete (and typically
destructors in the absense of garbage collection) also do memory
management, which is really a separate, unrelated issue.
if it never dies, so be it.
In the terms I'm using, if an object has a determinate lifetime,
it must be terminated at a specific point in time, in response
to a specific external event, or something similar. Regardless
of who has pointers to it. If an object has an indeterminate
lifetime, then it doesn't matter. In a very real sense, it is
never terminated (never dies); it just disappears. Its
"lifetime" never ends.
If it can die, well, knowing when it's quiescent is a _very_
important piece of information indeed.
You still haven't defined quiescent, and what it means with
regards to object lifetime.
You don't really want to terminate an object if it is still
able to be accessed by other entities.
You don't really have the choice, if your program is to work.
And it's not really a problem, if the other entities don't
actually access it. On the other hand, if the object doesn't
need termination, then you never terminate it, even when there
are no more pointers to it. It just "disappears"; it's
invisible (since there is no way to "see" it), and presumably,
it's memory will somehow be recycled, but that's it.
Therefore, I conclude that GC and/or reference counting can be
important tools for a lifetime management scheme to use in
Does that make any sense?
Not yet. I'm still having problems with vocabulary. My
interpretation of "quiescent", for example, implies that an
object will no longer change its state. But that can't be the
meaning your using---most of my dynamically allocated objects
which don't have explicit lifetimes are polymorphic agents
without any state.
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34