Disposing managed resources

[Varangian]

Hello,

was wondering of how to dispose of managed resources?

or referencing every member of a class to null will release
resources...?

http://www.marcclifton.com/tabid/79/Default.aspx
http://www.codeproject.com/managedcpp/garbage_collection.asp - sources

Thanks!

 

[Peter Duniho]

was wondering of how to dispose of managed resources?

It depends. Some classes implement IDisposable, and in some of those
cases, there are managed resources that can be "released" (unreferenced)
using the Dispose() method of that interface.

But I think that normally, there's not any need to dispose of managed
resources. It's the unmanaged ones you care about. Managed ones are,
by virtue of being managed, going to be cleaned up when there's a good
reason to clean them up, and otherwise left alone.

Since you shouldn't waste time cleaning something up when there's not a
good reason to, I think that for managed resources, just managing the
lifetime of the resource relative to your own use is sufficient.

More typically, you would use IDisposable to dispose of a resource that
is either unmanaged, or itself has unmanaged resources and thus
implements IDisposable.

or referencing every member of a class to null will release
resources...?

Setting references to null can allow a resource to be released. But it
doesn't necessarily do so right away. And I think that for managed
resources, you shouldn't even care whether they are or not.

http://www.marcclifton.com/tabid/79/Default.aspx

This seems to discuss the use of IDisposable to release unmanaged
resources. It seems to me, however, that the author doesn't really
understand the .NET memory model very well, nor does he really seem to
understand the true purpose of IDisposable (and he also doesn't seem to
understand that when you read a compressed image file to memory, of
course it has to be decompressed to be used and so occupies much more
memory than it does on disk...but that's a whole other issue ).

http://www.codeproject.com/managedcpp/garbage_collection.asp - sources

This article seems much better, but I'm not clear on how it is
specifically related to your question. It doesn't seem to me to discuss
the question of disposing managed resources per se, though it does
discuss IDisposable.

Pete

 

[Laura T.]

In fact, if the resource is "managed", then heck, let it be managed.

The only case where disposing managed resources *may* be useful is "acquire
late"/"release early" scenario.
That is, from the performance point of view, if you know that a big (big)
memory structure is not needed anymore but normally it would still be
rooted, it may help GC to dispose it and release references early so that GC
can, if it needs, to get more resources.
But it's not deterministic.
See http://blogs.msdn.com/brada/archive/2004/05/24/140645.aspx and links.

 

[Varangian]

In fact, if the resource is "managed", then heck, let it be managed.

The only case where disposing managed resources *may* be useful is "acquire
late"/"release early" scenario.
That is, from the performance point of view, if you know that a big (big)
memory structure is not needed anymore but normally it would still be
rooted, it may help GC to dispose it and release references early so that GC
can, if it needs, to get more resources.
But it's not deterministic.
Seehttp://blogs.msdn.com/brada/archive/2004/05/24/140645.aspxand links.

there are so many sources about how to use the IDisposable.... that's
what i thought that an image is an unmanaged resource.

so how the GC.SuppressFinalize comes into use? I read that this may
improve slightly insignificantly the performance... so that managed
object doesn't need to be finalized again because of its managed
resource. how would the SuppressFinalize come into use?

 

[Laura T.]

there are so many sources about how to use the IDisposable.... that's
what i thought that an image is an unmanaged resource.

The managed System.Drawing.Image holds an unmanaged resource (GDI handle),
so it must be disposed.
It's not 100% managed. Almost all System.Drawing hold unmanaged resources
and thus must be disposed as soon as possible.
Same goes for System.IO.* and many others.

so how the GC.SuppressFinalize comes into use? I read that this may
improve slightly insignificantly the performance... so that managed
object doesn't need to be finalized again because of its managed
resource. how would the SuppressFinalize come into use?

GC.SuppressFinalize() is intended only for Dispose(). It tells CLR that that
"I'm done. No more cleanup needed, thanks", by clearing a virtual "sorry,
could you please clean me up because someone forgot to do it?" flag.
CLR says "OK, thanks for the cooperation. Now I can just deallocate you
which is faster than remembering to call your Finalizer(), call it and then
deallocate. Good."
If you don't call (but you do) Dispose(), the object still has the "sorry,
could you please clean me up because someone forgot to do it?" fto lag set,
so CLR will take the trouble (but it makes it angry) to call the Finalizer()
(someday) to clear the flag and then deallocate.

So from your point of you (consumer of the object), you do not need (I'd say
must not) to call GC.SuppressFinalize() (taken that the Dispose() was
written correctly).
It won't help.

 

[Varangian]

The managed System.Drawing.Image holds an unmanaged resource (GDI handle),
so it must be disposed.
It's not 100% managed. Almost all System.Drawing hold unmanaged resources
and thus must be disposed as soon as possible.
Same goes for System.IO.* and many others.


GC.SuppressFinalize() is intended only for Dispose(). It tells CLR that that
"I'm done. No more cleanup needed, thanks", by clearing a virtual "sorry,
could you please clean me up because someone forgot to do it?" flag.
CLR says "OK, thanks for the cooperation. Now I can just deallocate you
which is faster than remembering to call your Finalizer(), call it and then
deallocate. Good."
If you don't call (but you do) Dispose(), the object still has the "sorry,
could you please clean me up because someone forgot to do it?" fto lag set,
so CLR will take the trouble (but it makes it angry) to call the Finalizer()
(someday) to clear the flag and then deallocate.

So from your point of you (consumer of the object), you do not need (I'd say
must not) to call GC.SuppressFinalize() (taken that the Dispose() was
written correctly).
It won't help.

thanks Laura .T.

the last part I didn't get it quite correctly... you said (taken that
the Dispose() was written correctly) how can you say that if the
Dispose method will supposedly do the SuppressFinalize?

 

[Peter Duniho]

[...]
there are so many sources about how to use the IDisposable.... that's
what i thought that an image is an unmanaged resource.

The classes derived from Image do have unmanaged resources. That's why
you should call Dispose() on them when you're done with them.

But you asked about disposing _managed_ resources. As both Laura and I
have mentioned, managed resources are already managed. You should not
usually need to do anything explicit with them in the way of disposal.

so how the GC.SuppressFinalize comes into use? I read that this may
improve slightly insignificantly the performance... so that managed
object doesn't need to be finalized again because of its managed
resource. how would the SuppressFinalize come into use?

As Laura mentioned, SuppressFinalize() is called by the managed object
when it is disposed, so that the finalizing code knows that it doesn't
need to run the class's finalizer when cleaning up the managed object.

Without calling SuppressFinalize(), a managed object will be finalized
as part of the garbage collection behavior. This is so that classes
that have unmanaged resources to be disposed get an opportunity to do so
even if the code that created the instance of that class did not call
Dispose().

Since the point is to catch the cases where some code erroneously fails
to call Dispose(), it is helpful to have a way to signal to the garbage
collector that Dispose() _has_ been called (or for whatever reason,
finalizing isn't required, though since finalizing is related to
IDisposable being implemented it seems to me that the questions of
whether Dispose() has been called and whether the finalizer should be
called go hand-in-hand). The SuppressFinalize() method is the way this
is done.

So, calling SuppressFinalize() is something that the class implementing
IDisposable does, in the Dispose() method. That way it doesn't have to
be unnecessarily disposed again by the finalizing logic.

Pete

 

[Varangian]

So I would be correct if it will (may) improve slightly the
performance when using GC.SuppressFinalize() on an instance?
even though inegligible? based on what you said!

Thanks Pete!

[...]
there are so many sources about how to use the IDisposable.... that's
what i thought that an image is an unmanaged resource.

The classes derived from Image do have unmanaged resources. That's why
you should call Dispose() on them when you're done with them.

But you asked about disposing _managed_ resources. As both Laura and I
have mentioned, managed resources are already managed. You should not
usually need to do anything explicit with them in the way of disposal.

so how the GC.SuppressFinalize comes into use? I read that this may
improve slightly insignificantly the performance... so that managed
object doesn't need to be finalized again because of its managed
resource. how would the SuppressFinalize come into use?

As Laura mentioned, SuppressFinalize() is called by the managed object
when it is disposed, so that the finalizing code knows that it doesn't
need to run the class's finalizer when cleaning up the managed object.

Without calling SuppressFinalize(), a managed object will be finalized
as part of the garbage collection behavior. This is so that classes
that have unmanaged resources to be disposed get an opportunity to do so
even if the code that created the instance of that class did not call
Dispose().

Since the point is to catch the cases where some code erroneously fails
to call Dispose(), it is helpful to have a way to signal to the garbage
collector that Dispose() _has_ been called (or for whatever reason,
finalizing isn't required, though since finalizing is related to
IDisposable being implemented it seems to me that the questions of
whether Dispose() has been called and whether the finalizer should be
called go hand-in-hand). The SuppressFinalize() method is the way this
is done.

So, calling SuppressFinalize() is something that the class implementing
IDisposable does, in the Dispose() method. That way it doesn't have to
be unnecessarily disposed again by the finalizing logic.

Pete

 

[Peter Duniho]

So I would be correct if it will (may) improve slightly the
performance when using GC.SuppressFinalize() on an instance?
even though inegligible? based on what you said!

My understanding is that, assuming you've written the rest of your code
correctly, adding a call to GC.SuppressFinalize() will have no effect on
performance (other than the extra time you waste making the call).

Pete