Dispose and freeing memory

  • Thread starter Thread starter Fernando Cacciola
  • Start date Start date
F

Fernando Cacciola

Help me out here please:

While watching Brad Abraham's MSDN TV talk about the Dispose pattern,
refering to:

public virtual void Dispose ( bool disposing )
{
if ( disposing )
{
<-- WHAT GOES HERE -->
}
}

He says: ..."here's were I'll free all my dependent objects, these are
things like managed resources... maybe you are in a form and you want to
free all the instances that are also on the form"...


I don't get that... how is Dispose going to help me free dependent objects
and managed resources? Isn't Dispose ONLY about releasing unmanaged
resources?

What am I missing?

TIA

Fernando Cacciola
 
In the Dispose() method is for example called on a container control you
could call the Dipose() method of alle the contained controls

Gabriel Lozano-Morán
 
Small correction. I believe that it should be "protected virtual void
Dispose(bool disposing)". This pattern solves the problems that occur
because your objects can be disposed in two different ways. The first is
explicitly and occurs when you call Dispose() on an object or create it via
a using statement. The second is when the garbage collector finds it.

In the first case, you are disposing the object yourself so you can have a
reasonable degree of confidence in the state of your managed objects. Thus
you can dispose them as well (if necessary).

In the case that the garbage collector disposes your objects, you do not
know there state. It is possible that the garbage collector disposed a
object to which you have a reference just before it disposed the parent
object. In that case you should only free up your unmanaged objects.
 
Fernando said:
Help me out here please:

While watching Brad Abraham's MSDN TV talk about the Dispose pattern,
refering to:

public virtual void Dispose ( bool disposing )
{
if ( disposing )
Click to expand...
[Just be aware that if disposing ==true, it means that you are disposing
it yourself, so you can explicitly dispose other managed resources. It's
a good practice that you dispose the resources when you are sure that
you are not using it. It may take days for GC to come back to clean the
resources.]
 
Jared Parsons said:
Small correction. I believe that it should be "protected virtual void
Dispose(bool disposing)".
Click to expand...

Yes, of course, I just typed that too fast.
This pattern solves the problems that occur because your objects can be
disposed in two different ways. The first is explicitly and occurs when
you call Dispose() on an object or create it via a using statement. The
second is when the garbage collector finds it.

In the first case, you are disposing the object yourself so you can have a
reasonable degree of confidence in the state of your managed objects.
Thus you can dispose them as well (if necessary).

In the case that the garbage collector disposes your objects, you do not
know there state. It is possible that the garbage collector disposed a
object to which you have a reference just before it disposed the parent
object. In that case you should only free up your unmanaged objects.
Click to expand...
I understand why you can only dispose of dependent managed objects inside
the

if ( disposing )
...

branch.

My question however is about the term "free an object" and its relation with
Dispose.

To me, and I'm pretty sure that to most anyone else, to "free an object"
means to reclaim the memory it uses.
But Dispose has nothing to do with (managed) memory.

Brad says earlier in his talk that "you use Dispose to a free an object",
but that's incorrect. Unless I'm totally missing something, Dispose has
nothing to do with freeing (i.e. reclaiming memory); it has to do with
releasing (notice the different term) unmanaged resources.

I truly believe that becasue of sources like Brad's talk many people think
Dispose() is about deterministcally destroying (thus freeing) an object. It
is not.
Calling Dispose() doesn't free the object at all; it just allows the object
to release any unmanaged resources it could be using. The managed memory
block used by the object (and all its dependent objects) will still be
allocated after the call to Dispose().

Please don't get me wrong: of course nor Brad nor you erroneusly think
Dispose() reclaimns managed memory, it's obvious you both know that well. My
point is that this stuff is wrongly explained because of a bad choice of
wording: Dispose() doesn't free up any managed objects, that's the job of
the GC and you just can't do that manually. Dispose() is ONLY about
releasing resources don't managed by the GC (thus called unmanaged
resources)

Fernando Cacciola
SciSoft
 
Hi,
My question however is about the term "free an object" and its relation
with Dispose.
Click to expand...

I think that the term "object" is not the best, you should say unmanaged
resource or something like that.

cheers,
 
Ignacio Machin ( .NET/ C# MVP ) said:
Hi,


I think that the term "object" is not the best, you should say unmanaged
resource or something like that.
Click to expand...
Right.. and I would even propose to say "release" instead of "free".

Anyway, my post was really intended to confirm that I had the right
concepts, not to nitpick on other people's errors.. even if it sounded like
that :-)

Best,

Fernando Cacciola
SciSoft
 
Ok, now I understand your question. You are correct that Dispose is not
actually freeing the memory associated with the object but allowing you to
release the associated resources. I would suggest that you add that
feedback to Brad's talk. I haven't actually watched that talk but from what
you are describing I can understand how that would confuse people.
 
Jared Parsons said:
Ok, now I understand your question. You are correct that Dispose is not
actually freeing the memory associated with the object but allowing you to
release the associated resources. I would suggest that you add that
feedback to Brad's talk. I haven't actually watched that talk but from
what you are describing I can understand how that would confuse people.
Click to expand...
Thanks for the response.
And great blog!

Best,

Fernando Cacciola
 
Back
Top