C# and garbage collection

[Kyle Kaitan]

I have got two classes, one is Device and the other is Buffer. Every Buffer
instance has an associated Device instance, since all Buffers have to be
created with Device.CreateBuffer(). Now i want to be able to notify an event
to all Buffer instances associated with a certain Device. At the same time i
would like the Buffer instances to be garbage collected, if there is no
reference from the client code (the one that called Device.CreateBuffer)
anymore. The problem is that the Device instance still holds a reference to
the otherwise unreferenced Buffer, preventing it from being garbage
collected.

I could solve the problem with a Destroy() method on the Buffer class, that
deletes itself from the notify-list of the Device instance. But having this
explicit destroy instruction is not really nice in a managed environment.

Someone's told me about WeakReference objects, but they look more like a
workaround than a solution. Any hints?

 

[Nicholas Paldino [.NET/C# MVP]]

Kyle,

Those are really the only two options you have. You wouldn't use a
Destroy method, but rather, you would implement IDisposable, and call
Dispose on the Device class. The Dispose method would notify the Device
that created it to let go.

The other way (and personally, I think more elegant way) would be to use
WeakReferences, as they are created for a situation like this. It would
prevent the need for a Dispose method. When you store the Buffers in the
Device instance, you would store WeakReferences. You could do general
cleanup every once in a while, reducing the list of WeakReferences that you
have, but that's about the only major obstacle.

Hope this helps.

 

[jdmartinez]

why isn't that nice? there's nothing wrong with explicitly calling
Destroy() or even Dispose() for that matter ... there's a whole
language construct dedicated to making sure Dispose() gets called
(using).

Joel Martinez
http://www.onetug.org - Orlando .NET User Group
http://www.codecube.net - blog

 

[J.Marsch]

I wouldn't say that there is anything wrong with using Dispose(), but I
would opt for the weak ref. If you rely on Dispose, then you are relying on
the developer who uses the code to remember to call dispose. If you use the
weak ref, it will "just work".

Personally, I'm not a real fan of dispose. The problem is consistency:
Some objects implement a dispose, and some don't. If you're paying
attention, good for you, but what about the guys who aren't? The fact that
it's only there some of the time, means that there is no habit-forming (with
Delphi, for example, if you created it, you destroyed it -- easy). Further,
if you have rev 1 of an object and it does not require a dispose, and then
in a future rev, you add one, now you potentially have a bunch of code to
track down and add disposes. When you think about it in terms of lifecycle,
the dispose pattern is really kind of ugly, and it's one of the very few
things about .Net that doesn't quite sit right with me.