Re: Thread-safe reference counts.
On Mar 31, 4:16 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:a810d31a-cbd1-4d9c-a2a7-b86a0b03dccc@a70g2000hsh.googlegroups.com...
On 30 mar, 02:29, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:c0da8427-0f37-4505-87d4-730f58f3adce@59g2000hsb.googlegroups.com..=
..
On 28 mar, 23:56, "Chris Thomasson" <cris...@comcast.net>
wrote:
"Jon Harrop" <use...@jdh30.plus.com> wrote in message
news:13uqrk9au723v0d@corp.supernews.com...
jason.cipri...@gmail.com wrote:
I have some code where objects are dynamically allocated by
some thread, and then used by multiple threads and freed
when they are no longer needed. I think that reference
counting is the most appropriate way to handle this in my
situation.
A concurrent garbage collector is the appropriate way to
handle that situation.
Why? There are many different ways to handle lifetime management.
Just to make it clear: the original posting talked about memory
management, not object lifetime management. From the way it was
presented, it more or less sounded like object lifetime had no
significance (often the case). In which case, garbage
collection is fine. But garbage collection has nothing to do
with object lifetime (which, when significant, still must be
managed, garbage collection or not).
GC does indeed detect when an object is not being referenced
by anything (e.g., in a quiescent state). IMHO, this is a
_very_ import part of lifetime management because you cannot
terminate an objects life if its being used by something else.
Garbage collection detects when an object can no longer be
referred to. Obviously, in this case, it's lifetime has ended,
since there is no longer any way to end it otherwise.
Right. The object is now quiescent.
I've not heard this term in relationship to object lifetime
management before. Generally speaking, I find that there are
two categories of objects, those with (or which need) a
deterministic lifetime, and those which don't. By "needing" a
deterministic lifetime", I mean that there is significant
(observable, in the sense of the C++ standard) behavior
associated with the end of their lifetime. If you loose all
pointers to the object before that behavior occurs, then you
have a serious error in your program. If you try to use the
object after that behavior has occured, then you also have a
serious error. Conceptually, for such objects, lifetime is
independent of the number of pointers to the object, although in
practice, you need to keep at least one pointer in order to
invoke the termination, and you don't want to keep pointers too
long after the object has been terminated, since any pointer to
the "dead" object is a potential source of errors. For such
objects, garbage collection isn't really that important in a
correct program, because freeing the memory at the point of
termination is always "correct". Garbage collection does help
in assertions against misuse, since it ensures that the memory
will not be used for something else as long as anyone still
holds a pointer to it. What I've often wished for in such cases
is some sort of reverse garbage collection: getting rid of the
pointers to the object because the object should no longer be
referenced. In practice, however, there doesn't seem to be any
effective generic means of "getting rid of the pointers": if the
pointer is in a map, for example, you have to remove the map
entry.
For objects with indeterminate lifetimes, of course, garbage
collection makes for less implementation code, so saves you
programming time.
But that's about it---garbage collection will not collect
the memory underneath the object that is still alive.
Provided, of course, that there are not errors in the code,
and you've lost the last pointer to the object before its
lifetime has ended. But that has nothing to do with object
lifetime per se.
IMHO, the ability to determine when an object is quiescent is
a major part of lifetime management as a whole.
Object lifetime is part of the design phase. If the design
specifies a determinate lifetime, you have to program it.
Regardless of the language---in this case, Java and C++ are no
different. If the design determines that it doesn't, *but* you
still need dynamic allocation (a lot of objects which don't have
pure value semantics, and should be copied, and not dynamically
allocated), then garbage collection saves you programming work.
But it never frees you of the responsibility of considering
object lifetime in design---it only intervenes at a much lower
level.
Most objects have indeterminate lifetime, and it doesn't
matter. If an object has determinate lifetime, however, you
have to manage it, garbage collection or no. Garbage
collection does NOT manage object lifetime; it only manages
memory.
Agreed. However, GC is a great tool to use in a lifetime
management scheme for dynamic objects.
Not for lifetime management. For memory management, once you've
determined that the lifetime is indeterminate (or after an
object with a determinate lifetime has been terminated).
--
James Kanze (GABI Software) email:james.kanze@gmail.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