garbage collection

[André]

Hello,

I have a c# application that creates a timer to fire every minute using
multithreading. On every minute it calls a Ping class that I made using
sockets.
It creates a new ping class then sets it to null when it’s done.

I noticed every time this class gets created I see the memory keeps getting
larger.
I think I should add Idisposable to my ping class and dispose of the memory
after the class is set to null.

Can someone give me their thoughts on this and maybe an example on how to
use the Idisposable class?
Thanks

[The Crow]

skeet, what u have seen is, Socket destructor calls Dispose(true); this is
not a necessarity. the sample code explains everything.
http://msdn.microsoft.com/library/de...sposeTopic.asp

[The Crow]

yes it seems interesting, but in respect to our discussion, finalizer or
desctructor does not call Dispose (at least destructor doesnt have to.).

one more interesting thing. compile and run that code. and see that it
definetly works!!

[The Crow]

sorry for the second paragraph. you can ignore it.

[Kevin Spencer]

The destructor is the finalizer. And the object will be destroyed when
Finalize() is called by the GC. Not before. Setting a field or variable to
null has no effect on the object it references. It is a pointer. You just
point it somewhere else. The object is unaffected.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"The Crow" <q> wrote in message
news:Ob******** ******@TK2MSFTN GP14.phx.gbl...

skeet, what u have seen is, Socket destructor calls Dispose(true); this is
not a necessarity. the sample code explains everything.
http://msdn.microsoft.com/library/de...sposeTopic.asp

[Willy Denoyette [MVP]]

Brian,

Right, the cases that the Finalizer doesn't run at all are rare, but you
would be supprised how many times I've seen it happen in scenarios where COM
interop is used on threads that are failing to pump the windows message
queue, or in Finalize methods that make blocking calls in unmanaged code
:-(.
Indeed, Constrained execution regions (CER's) are a great addition to the
framework, and a great tool in hosted environments.
Willy.
"Brian Gideon" <br*********@ya hoo.com> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...

I believe those rare cases where the finalizer doesn't run at all can
be mitigated with the new constrained execution regions technology in
version 2. It is an interesting addition to the framework.

Brian

Willy Denoyette [MVP] wrote:

Yes, this is what I want to stress, while it's true that the Finalizer
thread kicks in on request of a GC run, there no strong guarantee that
your
Finalize (that calls your Dispose(bool)) method will execute at the next
Finalizer run, there are (very rare) cases in which your Finalizer might
never be called at all. That said, when you expect deterministic disposal
of
your unmanaged resources, you need an explicit call to Dispose (or use
the
using statement for fine grained scopes), relying on the Finalizer offers
you non-deterministic disposals.
Willy.

[Willy Denoyette [MVP]]

Kevin,
The Finalize method is called on ran on the "finalizer" thread (an high
priority thread) after the GC has done it's marks/sweep run, but this
decision is mabe by the EE not directly by the GC, and only when there are
finalizable objects in the "ready for finalization" queue, when no such
objects are queued, the finalizer thread is not started (why would it?).

Willy.

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:ey******** *****@TK2MSFTNG P10.phx.gbl...

The destructor is the finalizer. And the object will be destroyed when
Finalize() is called by the GC. Not before. Setting a field or variable to
null has no effect on the object it references. It is a pointer. You just
point it somewhere else. The object is unaffected.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.

"The Crow" <q> wrote in message
news:Ob******** ******@TK2MSFTN GP14.phx.gbl...

skeet, what u have seen is, Socket destructor calls Dispose(true); this
is not a necessarity. the sample code explains everything.
http://msdn.microsoft.com/library/de...sposeTopic.asp

[Kevin Spencer]

Technically true, but you might as well say that an ignition key doesn't
cause exhaust fumes to exit the exhaust pipe of a car. It's a chain of
events that is all about Garbage Collection, and initialized by Garbage
Collection. In the context of this discussion, we're talking about objects
(Sockets) which WILL be finalized. The technical details are not
particularly relevant to this particular discussion. It all started with the
OP asking why his class was accumulating memory, and when told that he
needed to Dispose Sockets, he wanted to know why. Maybe I'm too concerned
with results. I do have my times of pure technological research, and it is
certainly worthwhile. However, those times don't occur when I'm trying to
debug something!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Kevin,
The Finalize method is called on ran on the "finalizer" thread (an high
priority thread) after the GC has done it's marks/sweep run, but this
decision is mabe by the EE not directly by the GC, and only when there are
finalizable objects in the "ready for finalization" queue, when no such
objects are queued, the finalizer thread is not started (why would it?).

Willy.

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:ey******** *****@TK2MSFTNG P10.phx.gbl...

The destructor is the finalizer. And the object will be destroyed when
Finalize() is called by the GC. Not before. Setting a field or variable
to null has no effect on the object it references. It is a pointer. You
just point it somewhere else. The object is unaffected.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.

"The Crow" <q> wrote in message
news:Ob******** ******@TK2MSFTN GP14.phx.gbl...

skeet, what u have seen is, Socket destructor calls Dispose(true); this
is not a necessarity. the sample code explains everything.
http://msdn.microsoft.com/library/de...sposeTopic.asp

[The Crow]

i think you didnt read the code example. here it is :

using System;
using System.Componen tModel;

public class DisposeExample
{
public class MyResource: IDisposable
{
private IntPtr handle;
private Component component = new Component();
private bool disposed = false;
public MyResource(IntP tr handle)
{
this.handle = handle;
}

public void Dispose()
{
Dispose(true);
GC.SuppressFina lize(this);
}

private void Dispose(bool disposing)
{
if(!this.dispos ed)
{
if(disposing)
{
component.Dispo se();
}

CloseHandle(han dle);
handle = IntPtr.Zero;
}
disposed = true;
}

[System.Runtime. InteropServices .DllImport("Ker nel32")]
private extern static Boolean CloseHandle(Int Ptr handle);

~MyResource()
{
Dispose(false); // This line is very important.... someone can
not include it.
}
}
public static void Main()
{
// Insert code here to create
// and use the MyResource object.
}
}

[Willy Denoyette [MVP]]

Hmm...I suppose it's me you are replying to, right?
When a class implement IDisposable it better adheres to the disposable
pattern, that is, a type that implements IDisposable should also have a
finalizer (called a destructor in C#), and that finalizer should call
Dispose(false).

But this is not my point, my point is that you should call dispose() when
you are done with the object if you want deterministic release of the
underlying resources, relying on finalize (your destructor ~) to call
Dispose(false) gives you non deterministic release, and should be avoided,
it's just a safety net to handle the cases that someone forgets to call
Dispose().

That's why I implement it as:

~MyResource()
{
Debug.Writeline ("BUG... you should call dispose instead of
relying on the finalizer");
Dispose(false);
}

I'm also not clear on what you mean by this:

// This line is very important.... someone can not include it. Guess you meant something like this:// This line is very important.... someone can not omit it.
Willy.

PS. Note the difference between Dispose() and Dispose(bool), in my replies?
the first must be called explicitely, the second is called by the finalize
methods (when the finalizer runs).
"The Crow" <q> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..i think you didnt read the code example. here it is :

using System;
using System.Componen tModel;

public class DisposeExample
{
public class MyResource: IDisposable
{
private IntPtr handle;
private Component component = new Component();
private bool disposed = false;
public MyResource(IntP tr handle)
{
this.handle = handle;
}

public void Dispose()
{
Dispose(true);
GC.SuppressFina lize(this);
}

private void Dispose(bool disposing)
{
if(!this.dispos ed)
{
if(disposing)
{
component.Dispo se();
}

CloseHandle(han dle);
handle = IntPtr.Zero;
}
disposed = true;
}

[System.Runtime. InteropServices .DllImport("Ker nel32")]
private extern static Boolean CloseHandle(Int Ptr handle);

~MyResource()
{
Dispose(false); // This line is very important.... someone can
not include it.
}
}
public static void Main()
{
// Insert code here to create
// and use the MyResource object.
}
}

[The Crow]

yes. the whole point is "call dispose() when as soon as you done your job"