Re: Thread-safe reference counts.
On Apr 2, 6:49 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1e8d3d15-c2e1-4968-9dff-e505d4ae77fe@m36g2000hse.googlegroups.com...
On Apr 1, 5:58 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1d6f13f6-f217-4609-8cf8-1d0226aea1d1@s50g2000hsb.googlegroups.com.=
...
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".
[...]
http://dictionary.reference.com/browse/quiescent%20
An object is at rest and has nothing to do.
Including being terminated? (I.e. termination is a no-op for
the object.) If termination is not a no-op, then it still has
something to do. Otherwise, the question isn't so much whether
it has something to do or not, but whether it can still be used
by other objects or not. If not, then it probably needs some
sort of explicit termination, in order to inform the other
objects that it is no longer usable (and of course, whatever
event made it unusable should trigger termination, and this
notification). If so, then it lives on forever. Conceptually,
at least---when no other object can reach it, it's memory can be
recycled for other uses.
When an object reaches that point in its lifetime it can
decide to safely destroy itself and/or safely reuse/cache
itself for later resurrection and re-initialization;
whatever....
Why does the object have to decide?
Or perhaps more to the point: why does the object have nothing
more to do: because it has reached a state from which it can do
nothing more (and so probably requires explicit termination), or
because it normally only has something to do as a result of
requests from another object, and no other object can reach it.
In the later case, of course, that state is irrelevant to the
object; it's exterior to the object, and the object (normally)
has no way of knowing, nor should it.
In the first case, garbage collection will not reap the object
if there are any remaining pointers to it, even if its lifetime
has ended; this allows some additional error checking. In the
second case, garbage collection can be said to play an enabling
role; without garbage collection, somehow, the fact that the
object has become unreachable must be determined manually, so
that the object can be freed. (In many cases, some form of
smart pointer will do the job adequately. In a few, however, it
is more complicated.)
In RCU speak an object is in a quiescent-state after its
rendered unreachable and has been successfully deferred
through the callback system. All concurrently accessing
threads within the epoch will go through a quiescent-state.
The information baking an epoch can be as fine-grain as an
embedded per-object proxy reference count, or it can be
coarse-grain, per-cpu and/or per-thread; whatever. When an
epoch goes quiescent, all objects contained within it have
also quiesced.
I'm not familiar with this vocabulary, so I'll pass on it.
--
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