Re: A re-announce on GC's defects

Michael D. Ober wrote:

You never have to call the IDispose interface. The GC will do this for you.

The GC never calls Dispose(). It makes its best effort to call
Finalize() as soon as possible if it's been overridden, but very few
disposable (implementing IDisposable) objects should have finalizers
(which should be restricted to handle-like objects).

The implementing Finalize() ("~ClassNameHere()" in C#) according to
recommended practices involves writing a protected virtual Dispose(bool)
method, but that's a separate (yet related) issue to implementing
IDisposable.

Do not confuse IDisposable with Finalize(). Any class overriding
Finalize() should implement IDisposable, but the reverse is *not* true.
Objects should implement IDisposable when they override Finalize, or if
they are the logical owner of any other resource which implements
IDisposable.

And ignore the horrific example of System.ComponentModel.Component. That
class is like a car accident :). You should implement Finalize() only on
handle-like classes, or preferably descend from SafeHandle (or one of
its descendants) and override the appropriate methods.

The runtime will eventually get around to releasing
those resources via the object's IDispose interface - you don't have to do
it yourself.

You've got the .NET GC wrong, I'm afraid. It knows nothing about
IDispose, or the Dispose() method. And it certainly tries hard to call
finalizers on finalizable objects (objects overriding the Finalize()
method) as soon as possible, but leaving resource deallocation up to the
GC is irresponsible and a recipe for bugs. It will leave sockets open,
files open and locked, database connections open etc. longer than
necessary, and will ultimately result in unexpected resource acquisition
failures.

For an easy life, deterministically dispose your resources, please!

In C#, the runtime will execute
the destruction code for you when it either has idle time or needs the
memory to satisfy a allocation request.

..NET doesn't have an exact analogue to C++ destruction. C++ destruction
combines two things: (1) memory disposal and (2) resource disposal. In
..NET, the GC does (1) and has facilities to catch (2) as a *last* line
of defense, while IDisposable is for (2).

You never need to call Dispose. By telling the compiler that an object
class implements IDisposable, the GC will call Dispose for you before it
actually deallocates memory.

Please, educate yourself before you spread more misinformation!

-- Barry

--
http://barrkel.blogspot.com/
.

Relevant Pages

  • Re: Delegates and Events confusion
    ... finalize is unneccessary, and not even fruitful. ... dispose and bypass an expensive finalization. ... >>If you subscribe to an event and do not unsubscribe, the subscriber will ... >>subscriptions that C makes and have C implement IDispose. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Memory Leak Experts!!!!
    ... you also implement the Finalize method which simply calles the Dispose ... >interface implementation has interfered with the normal function of the GC. ... >Deterministic disposing or implementing the IDispose pattern is only a ...
    (microsoft.public.dotnet.framework.performance)
  • Re: destructors
    ... > not run with the addition of constrained execution regions. ... >>> They are the same thing as the Finalize() function. ... >>> This is why the IDispose Interface was created. ... you just call Dispose(). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: destructors
    ... > by the Garbage Collector. ... > This is why the IDispose Interface was created. ... Dispose() and Finalize() are 2 different methods called at different time! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Automatic Dispose
    ... But, a SqlConnection itselft is a managed resource and, as such, should not ... instance user uses "Using" and Dispose is called automatically). ... Public Overridable Sub Dispose() Implements IDisposable.Dispose ... Protected Overrides Sub Finalize() ...
    (microsoft.public.dotnet.languages.vb)