GC, the simple solution

[Lionello Lunesu]

"Frank Benoit" <keinfarbton at nospam.xyz> wrote in message 
news:e5uojm$18ji$1 at digitaldaemon.com...
> Lionello Lunesu schrieb:
>>> * Destructors are called immediatly if the counter goes zero.
>>
>> This is not such a good thing! You don't really know who releases the 
>> last
>> reference, so you don't really know when the object is deleted. If the
>> object is being referenced from multiple threads, you don't know in what
>> thread the destructor will run.
>>
>
> Where is the disadvantage? If you release concurrent in different
> threads you need some kind of syncronization. Than you know it. But this
> is no issue of ref counting.
> If you release a reference in the phobos GC, the object is collected
> "perhaps" the next time. If there are no valid integer values,
> "pointing"to your object. And after collecting, the sequence of
> destructor calls is not defined.

There are many resources that must be released by the thread by which they 
were acquired. There's not much synchronisation can do. If the last 
reference just happens to be released in a thread other than the one that 
created the object, then the resource will be released in the wrong thread.

As I've understood from Boehm's paper, one advantages of a GC is to fix this 
issue: a GC collect will call finalizers for the objects that were created 
in that thread. It's like keeping an object from being destructed until the 
thread that created the object calls malloc (which is were the GC does its 
thing).

Anyway, Boehm's paper is a good read. He (she?) also addresses the problems 
with reference counting.

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

>>> * Member objects are still valid, while a destructor is called. => no
>>> more dispose/close patterns
>>
>> When an object is being destructed, the references it has to other 
>> objects
>> are being released. So in the destructor of object B, object A might have
>> released about half its references.
>
> If object B Dtor is called, its member variables are valid, and valid is
> the object A. The B.~this() can do something with A. After the Dtor is
> finished, the reference to A is nulled, and A is perhaps also deleted.
> Seams perfect to me.

I meant my example like this: object A has a reference to object B. During 
the destruction of A, the references it has to other objects are released, 
causing some objects being destructed, like B. Now B might (indirectly) use 
data from A, but A's in the middle of destruction. What I mean to tell with 
all this is that you still have to be carefull with your destructors. 
Especially when using a strong-pointer template. You can't always tell what 
state other objects are in in a destructor. They might be half way during 
destruction, having released some, but not all, of their references.

L.