Re: Disposing managed resources


"Varangian" <ofmars@xxxxxxxxx> ha scritto nel messaggio news:1191402348.513390.264650@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Oct 3, 9:49 am, "Laura T." <LT_s...@xxxxxxxxx> wrote:
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.

"Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx> ha scritto nel messaggionews:13g5o4hhmq4gi46@xxxxxxxxxxxxxxxxxxxxx

> Varangian wrote:
>> 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

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.

.

Relevant Pages

  • Re: Bitmap constructor throwing System.Exception
    ... > calling Dispose() repeatedly may actually cause more problems if the users ... the virtual nature of memory on the PPC ... > possibility that long lived objects may be eating up available resources. ... >> problem is caused by the lack of managed memory. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Bitmap constructor throwing System.Exception
    ... If your hope is to prevent the absorption of resources... ... calling Dispose() repeatedly may actually cause more problems if the users ... the virtual nature of memory on the PPC ... >> does not force the garbage collector to spin through unused objects at ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: What does GC.GetTotalMemory really tell us?
    ... > Disposing boy was to free up memory resources, ... Dispose doesn't really say anything about GC - it isn't usually used ... Console.WriteLine("Memory with hog:\t", howMuchDuring); ...
    (microsoft.public.dotnet.framework)
  • Re: Disposing managed resources
    ... can, if it needs, to get more resources. ... using the Dispose() method of that interface. ... understand the .NET memory model very well, nor does he really seem to ... Almost all System.Drawing hold unmanaged resources ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: what are unmanaged resources
    ... the GC will come along and clean up all the memory and resources associated ... in a deterministic fashion and clean up unmanaged resources. ... placed inside the Dispose functions. ... sooner than later (i.e. by waiting for the garbage collector) and you should ...
    (microsoft.public.dotnet.languages.csharp)
Loading