Dispose / Finalize - not 'getting' it

[Larry Lard]

I still don't really 'get' this. Why can't an object just release its
resources in its Finalize method? Why when I create (eg) a Graphics
object does it become *my* responsibility to say when I've finished
with it, and explcitly say so? I thought one of the points of managed
memory / garbage collection was that users of objects didn't have to
worry about tracking object lifetime?

What's the point of me saying g.Dispose at the end of my drawing
routine, when this is going to happen when g dies anyway?

Why do I have to check with every object I use whether or not it
implements IDisposable, and if it does then track its lifetime myself?
How is this better or more reliable than manual reference counting?

Lots of question marks but only one question, really. Any insight
welcome!

 

[dgk]

I still don't really 'get' this. Why can't an object just release its
resources in its Finalize method? Why when I create (eg) a Graphics
object does it become *my* responsibility to say when I've finished
with it, and explcitly say so? I thought one of the points of managed
memory / garbage collection was that users of objects didn't have to
worry about tracking object lifetime?

What's the point of me saying g.Dispose at the end of my drawing
routine, when this is going to happen when g dies anyway?

Why do I have to check with every object I use whether or not it
implements IDisposable, and if it does then track its lifetime myself?
How is this better or more reliable than manual reference counting?

Lots of question marks but only one question, really. Any insight
welcome!

Seems to be an issue of managed resources vs unmanaged resources.
Helps not, right?

Well, anyway, in VB2005 you can use USING (no, not the one at the top
of the Class) to automatically dispose of those pesky unmanaged
resources. Like this:

Dim XXX As System.Drawing.Graphics
Using XXX
' do something here with XXX
End Using

and POOF! XXX is gone. As is, I think, anything else declared in the
construct.

So, all you have to do now is know what objects require Using - which
sort of leaves us where we started.

This is from the help file:
Sometimes your code requires an unmanaged resource, such as a file
handle, a COM wrapper, or a SQL connection. A Using block guarantees
the disposal of one or more such resources when your code is finished
with them. This makes them available for other code to use.

 

[Armin Zingler]

I still don't really 'get' this. Why can't an object just release
its resources in its Finalize method? Why when I create (eg) a
Graphics object does it become *my* responsibility to say when I've
finished with it, and explcitly say so? I thought one of the points
of managed memory / garbage collection was that users of objects
didn't have to worry about tracking object lifetime?

What's the point of me saying g.Dispose at the end of my drawing
routine, when this is going to happen when g dies anyway?

Why do I have to check with every object I use whether or not it
implements IDisposable, and if it does then track its lifetime
myself? How is this better or more reliable than manual reference
counting?

It's better because you don't have to clean it up on your own. Automatic
memory management is related to the .Net objects. You don't have to call
'GlobalAlloc' or 'GlobalFree' anywhere to reserve/release memory.

Concerning Dispose: You are usually not forced to call it, but Dipose gives
you the ability to free resources *immediatelly* without having to wait for
the GC to collect the objects and freeing resources in their finalize
methods. This is helpful because some unmanaged resources are limited. If
you would wait for the object to be destroyed, you might run into a lack of
free resources, e.g. database connections or limited GDI objects on older
OS versions or other limited (system) resources.

So, the distinction is: managed resources are almost unlimited, i.e. the
limit is usually the RAM available, and the GC handles this, whereas
unmanaged resources might be limited or, in some cases, allocation and
destruction of resources even must be used in pairs.

Lots of question marks but only one question, really. Any insight
welcome!

Armin

 

[Mattias Sjögren]

Why can't an object just release its
resources in its Finalize method?

In addition to what the others said, there are also sometimes thread
affinity reasons. Some native resources must be released on the same
thread as they were allocated. Since finalizers run on a dedicated
thread it may not be possible to free the resource from Finalize.


Mattias

 

[Brian Gideon]

Mattias,

It's is interesting that you mention that because I just started a
thread about that very topic a few days ago in
microsoft.public.dotnet.general. I suspect that it's unlikely that
anyone would have to deal with that issue. I don't know of many APIs
that have thread affinity issues.

Brian