Develop Reference

Calling dispose within list.removeAll

I'm pretty new to C# programming, and the concept of the GC, and its realtions to IDisposable is still a bit vague. What does calling Dispose mean in terms of the garbage collection?
Specifically i wonder if the following code may fail occationally, depending on when the garbage collection kicks in. (I have not been able to make it crash during my tests).
//List<TestClass2> tc2List;
//TestClass2 invokes a thread. It implements IDisposable.
//Its Dispose() sets a stop-condition for the thread,
//and joins the thread, awaiting it to stop. (may take 100 msek)
tc2List.RemoveAll(t =>
{
if (String.Compare(t.Name, "Orange") == 0)
{
t.Dispose(); //May take up to 100 msek
return true;
}
return false;
});

Your code works, but it's bad style. Predicates should not have side effects. So you should first dispose the elements, and then remove them.
Predicate<T> filter = t => t.Name == "Orange";
foreach(var t in tc2List.Where(filter))
t.Dispose();
tc2List.RemoveAll(filter);

i wonder if the following code may fail occationally, depending on when the garbage collection kicks in
No, it won't fail
//Its Dispose() sets a stop-condition for the thread,
//and joins the thread, awaiting it to stop. (may take 100 msek)
That is a slightly a-typical use of Dispose() but not wrong. A more efficient approach would use a different Stop() so that you can stop all threads at once. Or call Dispose() from Parallel.ForEach(). But whatever method you choose, it is not hindering, nor is it being hindered by, the GC.

Do you have finalize method in you TestClass2?
Dispose main properties
This has to be implemented in classes implementing IDispose interface.
Its the right place for freeing-up unmanaged resources like file, handles, and connections etc.
Dispose() method is called explicitely in the code itself.
Dispose() method is automatically called (for objects which implement IDispose), when used in a "using"
Refer to link.

What does calling Dispose mean in terms of the garbage collection?
Calling dispose, means you are forcibly cleaning up things (literally the memory) using your implementation of the Dispose method. Note : (Some of the framework classes do call your implementation of Dispose for you. System.Windows.Forms.Form for example)
Garbage collection on the contrast is a feature of the .NET runtime that will clean up things for you automatically. Automatically i mean, because its up to the memory pressure and other factors that is taken care by the runtime.
A simple strategy i would recommend. Do Dispose() if you think that the memory would stay longer than needed and would impact the application. Else leave it to the runtime, it will automatically cleans up (i.e finalizes) the objects when they go out of scope. The GC has its own algorithm on how to do cleanup, but you can to a greater extent rely on it.
The next question
Specifically i wonder if the following code may fail occasionally, depending on when the garbage collection kicks in
I guess no. Failure of the code due to GC kicking in, depends on how you write the finalizer of TestClass2. Definitely your call t.Dispose() wont clash with the GC.

For Microsoft built classes that inherit IDisposable, do I explicitly have to call Dispose?

Regarding the Microsoft built classes that inherit IDisposable, do I explicitly have to call Dispose to prevent memory leaks?
I understand that it is best practice to call Dispose (or better yet use a using block), however when programming, typically I don't always immediately realise that a class inherits from IDisposable.
I also understand that Microsoft implementation of IDisposable is a bit borked, which is why they created the article explaining the correct usage of IDisposable.
Long story short, in which instances is it okay to forget to call Dispose?

There are a couple of issues in the primary question
Do I explicitly have to call Dispose to prevent memory leaks?
Calling Dispose on any type which implements IDisposable is highly recomended and may even be a fundamental part of the types contract. There is almost no good reason to not call Dispose when you are done with the object. An IDisposable object is meant to be disposed.
But will failing to call Dispose create a memory leak? Possibly. It's very dependent on what exactly that object does in it's Dispose method. Many free memory, some unhook from events, others free handles, etc ... It may not leak memory but it will almost certainly have a negative effect on your program
In which instances is it okay to forget to call Dispose?
I'd start with none. The vast majority of objects out there implement IDisposable for good reason. Failing to call Dispose will hurt your program.

It depends on two things:
What happens in the Dispose method
Does the finalizer call Dispose
Dispose functionlity
Dispose can do several type of actions, like closing a handle to a resource (like file stream), change the class state and release other components the class itself uses.
In case of resource being released (like file) there's a functionality difference between calling it explicitly and waiting for it to be called during garbage collection (assuming the finalizer calls dispose).
In case there's no state change and only components are released there'll be no memory leak since the object will be freed by the GC later.
Finalizer
In most cases, disposable types call the Dispose method from the finalizer. If this is the case, and assuming the context in which the dispose is called doesn't matter, then there's a high chance that you'll notice no difference if the object will not be disposed explicitly. But, if the Dispose is not called from the finalizer then your code will behave differently.
Bottom line - in most cases, it's better to dispose the object explicitly when you're done with it.
A simple example to where it's better to call Dispose explicitly: Assuming you're using a FileStream to write some content and enable no sharing, then the file is locked by the process until the GC will get the object. The file may also not flush all the content to the file so if the process crashes in some point after the write was over it's not guaranteed that it will actually be saved.

It can be safe to not call Dispose, but the problem is knowing when this is the case.
A good 95% of IEnumerator<T> implementations have a Dispose that's safe to ignore, but the 5% is not just 5% that'll cause a bug, but 5% that'll cause a nasty hard to trace bug. More to the point, code that gets passed an IEnumerator<T> will see both the 95% and the 5% and won't be able to dynamically tell them apart (it's possible to implement the non-generic IEnumerable without implementing IDisposable, and how well that turned out can be guessed at by MS deciding to make IEnumerator<T> inherit from IDisposable!).
Of the rest, maybe there's 3 or 4% of the time it's safe. For now. You don't know which 3% without looking at the code, and even then the contract says you have to call it, so the developer can depend on you doing so if they release a new version where it is important.
In summary, always call Dispose(). (I can think of an exception, but it's frankly too weird to even go into the details of, and it's still safe to call it in that case, just not vital).
On the question of implementing IDisposable yourself, avoid the pattern in that accursed document.
I consider that pattern an anti-pattern. It is a good pattern for implementing both IDisposable.Dispose and a finaliser in a class that holds both managed and unmanaged resources. However holding both managed IDisposable and unmanaged resources is a bad idea in the first place.
Instead:
If you have an unmanaged resource, then don't have any unmanaged resources that implement IDisposable. Now the Dispose(true) and Dispose(false) code paths are the same, so really they can become:
public class HasUnmanaged : IDisposable
{
IntPtr unmanagedGoo;
private void CleanUp()
{
if(unmanagedGoo != IntPtr.Zero)
{
SomeReleasingMethod(unmanagedGoo);
unmanagedGoo = IntPtr.Zero;
}
}
public void Dispose()
{
CleanUp();
GC.SuppressFinalize(this);
}
~HasUnmanaged()
{
CleanUp();
}
}
If you have managed resources that need to be disposed, then just do that:
public class HasUnmanaged : IDisposable
{
IDisposable managedGoo;
public void Dispose()
{
if(managedGoo != null)
managedGoo.Dispose();
}
}
There, no cryptic "disposing" bool (how can something be called Dispose and take false for something called disposing?) No worrying about finalisers for the 99.99% of the time you won't need them (the second pattern is way more common than the first). All good.
Really need something that has both a managed and an unmanaged resource? No, you don't really, wrap the unmanaged resource in a class of your own that works as a handle to it, and then that handle fits the first pattern above and the main class fits the second.
Only implement the CA10634 pattern when you're forced to because you inherited from a class that did so. Thankfully, most people aren't creating new ones like that any more.

It is never OK to forget to call Dispose (or, as you say, better yet use using).
I guess if the goal of your program is to cause unmanaged resource leaks. Then maybe it would be OK.

The implementation of IDisposable indicates that a class uses un-managed resources. You should always call Dispose() (or use a using block when possible) when you're sure you're done with the class. Otherwise you are unnecessarily keeping un-managed resources allocated.
In other words, never forget to call Dispose().

Yes, always call dispose. Either explicitly or implicitly (via using). Take, for example, the Timer class. If you do not explicitly stop a timer, and do not dispose it, then it will keep firing until the garbage collector gets around to collecting it. This could actually cause crashes or unexpected behavior.
It's always best to make sure Dispose is called as soon as you are done with it.

Microsoft (probably not officially) says it is ok to not call Dispose in some cases.
Stephen Toub from Microsoft writes (about calling Dispose on Task):
In short, as is typically the case in .NET, dispose aggressively if
it's easy and correct to do based on the structure of your code. If
you start having to do strange gyrations in order to Dispose (or in
the case of Tasks, use additional synchronization to ensure it's safe
to dispose, since Dispose may only be used once a task has completed),
it's likely better to rely on finalization to take care of things. In
the end, it's best to measure, measure, measure to see if you actually
have a problem before you go out of your way to make the code less
sightly in order to implement clean-up functionality.
[bold emphasize is mine]
Another case is base streams
var inner = new FileStrem(...);
var outer = new StreamReader(inner, Encoding.GetEncoding(1252));
...
outer.Dispose();
inner.Dispose(); -- this will trigger a FxCop performance warning about calling Dispose twice.
(I have turned off this rule)

How to Dispose myClass with Garbage Collecter C#

I have a class and got a method that doin so many things in memory and need to be disposed when its jobs done.But i have looked for MSDN for solution.There is an example thats not solved my problem.When my Class is instanced and run this method my memory is getting bigger and bigger.How can i Dispose it when its job done ?
Here is my CODES ;
class Deneme
{
public Deneme()
{ }
~Deneme()
{
GC.Collect();
GC.SuppressFinalize(this);
}
public void TestMetodu()
{
System.Windows.Forms.MessageBox.Show("Test");
// This is my method that doing big jobs :)
}
}
Deneme CCCX = new Deneme();
CCCX.TestMetodu();
CCCX = null;
So i cant dispose it with this.

~Deneme()
{
GC.Collect();
GC.SuppressFinalize(this);
}
You don't need to use GC.Collect() or GC.SuppressFinalize(this);, because at this point, the garbage collector is already collecting the object.
You want to use the Dispose method, so you can encapsulate the object use in a using statement. Here is a link that will show you the pattern on how to implement it:
http://www.c-sharpcorner.com/UploadFile/Ashish1/dispose02152006095441AM/dispose.aspx
link to MSDN:
http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx
private bool IsDisposed
{
get;set;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~CLASS_NAME()
{
Dispose(false);
}
protected virtual void Dispose(bool disposedStatus)
{
if (!IsDisposed)
{
IsDisposed = true;
// Released unmanaged Resources
if (disposedStatus)
{
// Released managed Resources
}
}
}

implement IDisposable (with function Dispose) and then wrap the creation of your object in a using statement. (when the object goes out of scope (after the using block), the dispose will be called.)
Furthermore, never call GC.Collect().

Does your class directly use any unmanaged resources, or hold references to any IDisposable objects? If so, then you should probably implement IDisposable to clean-up those resources, and then wrap all uses of your class in a using block.
If your class only uses managed resources, and doesn't hold references to any IDisposable objects, then you should probably let the GC do its job without any interference. Just ensure that the lifetime of any instances of your class are kept as short as possible.

I think there are a few issues here and you need to look into this in a little more detail, the .net garbage collector usually does a pretty good job on its own and needs verly litle help from the developer.
Use the Dispose interface if you
really really need to (usually this
is to release any unmanaged
resources you may have used)
dont call gc.collect(), you can
really mess up the garbage
collection cycle
in you code use the using statement
on any objects that impliment
idisposable to ensure they are made
available for collection as soon as
possible.
To me it seems you need to look at the "big jobs" as it seems there may be a memory leak there, proper coding of that would probably alleviate the need to do any cleaning up afterwards.
here is a good read on GC

Well, I don't quite understand your example. If you hold unmanaged resources (like File handles etc.) you want to implement IDisposable and override the member it provides, Dispose.
There is a recommended pattern when using IDisposable which you can read about at the .NET docs for IDisposable.
However this is not a guarantee that your object will be collected when you call Dispose, only that the resources it uses is freed (as long as you've implemented your class correctly of course.) As the documentation states:
The primary use of this interface is
to release unmanaged resources. The
garbage collector automatically
releases the memory allocated to a
managed object when that object is no
longer used. However, it is not
possible to predict when garbage
collection will occur. Furthermore,
the garbage collector has no knowledge
of unmanaged resources such as window
handles, or open files and streams.
Use the Dispose method of this
interface to explicitly release
unmanaged resources in conjunction
with the garbage collector. The
consumer of an object can call this
method when the object is no longer
needed.
IDisposable is only there for freeing unmanaged resources, your class however is managed. It is under the control of the garbage collector.
What I think you are asking for is managing the lifetime of the managed object (your class), which is as far as I know not recommended unless there is a really really strong reason to. I don't exactly have the most exotic needs but I've never had to do this myself.

It's normal for an application to use more and more memory (up to a certain point) until the memory is needed for something else. There is no reason for the application to waste time with cleaning up unused objects if the memory isn't needed, the computer doesn't run any faster from having a lot of unused memory.
If the application continues to grow uncontrollably, then you have a problem. If the memory goes back down after a while, it's not a problem. You can test to minimise the program, that normally causes it to return as much memory to the system as possible.
If you are using objects in your method that implements IDisposable you should make sure that they are disposed properly. Otherwise they can't be cleaned up until the garbage collector has first called the Finalize method on each of them. There is a background thread that runs Finalize calls one at a time, so if you leave a lot of objects undisposed, it can take a while until they are all processed and ready to be cleaned up by garbage collection.

C# - Are objects immediately destroyed when going out of scope?

Can I trust that an object is destroyed and its destructor is called immediately when it goes out of scope in C#?
I figure it should since many common coding practices (e.g. transaction objects) rely on this behaviour, but I'm not very used to working with garbage collection and have little insight to how such languages usually behave.
Thanks.

Nope, .Net and hence C# relies on a garbage collection memory management. So destructors (which in .Net is called finalizers) are not called until GC finds it proper to destroy the objects.
Additionally: most "regular" objects in C# don't have destructors. If you need the destructor pattern you should implement the IDisposable interface with the Dispose Pattern. On disposable objects you should also make sure that the Dispose method gets called, either with the using keyword or directly calling the method.
To further (hopefully) clarify: deterministic disposal is useful in .Net e.g. when you need to explicitly free resources that is not managed by the .Net runtime. Examples of such resources are file handles, database connections, etc. It is usually important that these resources be freed as soon as they no longer are needed. Thus we cannot afford to wait for the GC to free them.
In order to get deterministic disposal (similar to the scope behavior of C++) in the non-deterministic world of the .Net GC, the .Net classes rely on the IDisposable interface. Borrowing from the Dispose Pattern, here are some examples:
First, instantiating a disposable resource and then letting the object go out of scope, will leave it up to the GC to dispose the object:
1. {
2. var dr = new DisposableResource();
3. }
To fix this we can explicitly dispose the object:
1. {
2. var dr = new DisposableResource();
3.
4. ...
5.
6. dr.Dispose();
7. }
But what if something goes wrong between line 2 and 6? Dispose will not be called. To further ensure that Dispose will finally be called regardless of any exceptions we can do the following:
1. var dr = new DisposableResource();
2. try
3. {
4. ...
5. }
6. finally
7. {
8. dr.Dispose();
9. }
Since this pattern is often needed, C# includes the using keyword to simplify things. The following example is equivalent to the above:
1. using (var dr = new DisposableResource())
2. {
3. ...
4. }

No. An object doesn't actually go "out of scope," the reference to it (i.e. the variable you use to access it) does.
Once there are no more references to a given object, that object becomes eligible for garbage collection (GC) should the need arise. Whenever the GC decides it needs to reclaim the space your no-longer-referenced object, that's when the objects finalizer will be called.
If your object is a resource (e.g. a file handle, database connection), it should implement the IDisposable interface (which obligates the object to implement a Dispose() method to clean up any open connections, etc). The best practice for you in this case would be to create the object as part of a using block, so that when this block is completed, your application will automatically call the objects Dispose() method, which will take care of closing your file/db connection/whatever.
e.g.
using (var conn = new DbConnection())
{
// do stuff with conn
} // conn.Dispose() is automatically called here.
The using block is just some syntactic sugar which wraps your interactions with the conn object in a try block, along with a finally block which only calls conn.Dispose()

There is no such thing als a C++-like destructor in C#. (There is a different concept of destructor in C#, also called a finalizer, which uses the same syntax as C++ destructors, but they are unrelated to destroying objects. They're intended to provide a cleanup mechanism for unmanaged resources.)
The garbage collector will cleanup objects sometime after they are no longer referenced. Not immediately, and there is no way to guarantee this either.
Luckily there is also no real reason why you would want to guarantee this. If you need the memory, then the GC will reclaim it then. If you don't, why care if there's still some garbage object around? It's not a memory leak: the GC can still find it and clean it up any time.

No, this isn't guaranteed. Similar to languages such as Java, in C# the garbage collector runs when it's needed (i. e. when the heap is getting too full). However, when your objects implement IDisposable, i. e. they have a Dispose() method and it has to be called, then you can take advantage of the using keyword:
using (var foo = new DisposableObject()) {
// do something with that
}
That way Dispose() will be called immediately when leaving that using block.
Note: IDisposable is found in many types, most notably GDI+ but also database connections, transactions, etc. so it may really be the right pattern here.
Note 2: Behind the scenes above block will get translated into a try/finally block:
var foo = new DisposableObject();
try
{
// do something with that
}
finally
{
foo.Dispose();
}
But that translation is done by the compiler and very handy for not forgetting to call Dispose().

I don't think you should rely on garbage collectors in this way. Even if you deduct how they operate it might very well be that in the next release they've reimplemented it.
In any case, objects are not garbage collected the moment you unreference them. Typically they are collected until some threshold is reached and then they are released.
Especially in java programs this is very noticeable when you look at the memory consumption on the task manager. It grows and grows and all of a sudden every minute it drops again.

No. If you refer to CLI specification (p. 8.9.6.7 about Finalizers) http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf you can find the following
the CLI should ensure that finalizers are called soon after the instance becomes
inaccessible. While relying on memory pressure to
trigger finalization is acceptable, implementers should consider the use of additional
metrics
but it must not.

How do I track down where I've been leaking IDisposable objects from?

I've been debugging some code recently that was a bit memory leaky. It's a long running program that runs as a Windows service.
If you find a class wearing an IDisposable interface, it is telling you that some of the resources it uses are outside the abilities of the garbage collector to clean up for you.
The reason it is telling you this is that you, the user of this object, are now responsible for when these resources are cleaned up. Congratulations!
As a conscientious developer, you are nudged towards calling the .Dispose() method when you've finished with the object in order to release those unmanaged resources.
There is the nice using() pattern to help clean up these resources once they are finished with. Which just leaves finding which exact objects are causing the leakyness?
In order to aid tracking down these rogue unmanaged resources, is there any way to query what objects are loitering around waiting to be Disposed at any given point in time?

There shouldn't be any cases where you don't want to call Dispose, but the compiler cannot tell you where you should call dispose.
Suppose you write a factory class which creates and returns disposable objects. Should the compiler bug you for not calling Dispose when the cleanup should be the responsibility of your callers?

IDisposable is more for making use of the using keyword. It's not there to force you to call Dispose() - it's there to enable you to call it in a slick, non-obtrusive way:
class A : IDisposable {}
/// stuff
using(var a = new A()) {
a.method1();
}
after you leave the using block, Dispose() is called for you.

"Is there any way to detect at the end of the program which objects are loitering around waiting to be Disposed?"
Well, if all goes well, at the end of the program the CLR will call all object's finalizers, which, if the IDisposable pattern was implemented properly, will call the Dispose() methods. So at the end, everything will be cleared up properly.
The problem is that if you have a long running program, chances are some of your IDiposable instances are locking some resources that shouldn't be locked. For cases like this, user code should use the using block or call Dispose() as soon as it is done with an object, but there's really no way for a anyone except the code author to know that.

You are not required to call the Dispose method. Implementing the IDisposable interface is a reminder that your class probably is using resources such as a database connection, a file handle, that need to be closed, so GC is not enough.
The best practice AFAIK is to call Dispose or even better, put the object in a using statement.

A good example is the .NET 2.0 Ping class, which runs asynchronously. Unless it throws an exception, you don't actually call Dispose until the callback method. Note that this example has some slightly weird casting due to the way Ping implements the IDisposable interface, but also inherits Dispose() (and only the former works as intended).
private void Refresh( Object sender, EventArgs args )
{
Ping ping = null;
try
{
ping = new Ping();
ping.PingCompleted += PingComplete;
ping.SendAsync( defaultHost, null );
}
catch ( Exception )
{
( (IDisposable)ping ).Dispose();
this.isAlive = false;
}
}
private void PingComplete( Object sender, PingCompletedEventArgs args )
{
this.isAlive = ( args.Error == null && args.Reply.Status == IPStatus.Success );
( (IDisposable)sender ).Dispose();
}

Can I ask how you're certain that it's specifically objects which implement IDisposable? In my experience the most-likely zombie objects are objects which have not properly had all their event handlers removed (thereby leaving a reference to them from another 'live' object and not qualifying them as unreachable during garbage collection).
There are tools which can help track these down by taking a snapshot of the managed heap and stacks and allowing you to see what objects are considered in-use at a given point in time. A freebie is windbg using sos.dll; it'll take some googling for tutorials to show you the commands you need--but it works and it's free. A more user-friendly (don't confused that with "simple") option is Red Gate's ANTS Profiler running in Memory Profiling mode--it's a slick tool.
Edit: Regarding the usefulness of calling Dispose--it provides a deterministic way to cleanup objects. Garbage Collection only runs when your app has ran out of its allocated memory--it's an expensive task which basically stops your application from executing and looks at all objects in existance and builds a tree of "reachable" (in-use) objects, then cleans up the unreachable objects. Manually cleaning up an object frees it before GC ever has to run.

Because the method creating the disposable object may be legitimately returning it as a value, that is, the compiler can't tell how the programming is intending to use it.

What if the disposable object is created in one class/module (say a factory) and is handed off to a different class/module to be used for a while before being disposed of? That use case should be OK, and the compiler shouldn't badger you about it. I suspect that's why there's no compile-time warning---the compiler assumes the Dispose call is in another file.

Determining when and where to call Dispose() is a very subjective thing, dependent on the nature of the program and how it uses disposable objects. Subjective problems are not something compilers are very good at. Instead, this is more a job for static analysis, which is the arena of tools like FxCop and StyleCop, or perhaps more advanced compilers like Spec#/Sing#. Static analysis uses rules to determine if subjective requirements, such as "Always ensure .Dispose() is called at some point.", are met.
I am honestly not sure if any static analyzers exist that are capable of checking whether .Dispose() is called. Even for static analysis as it exists today, that might be a bit on the too-subjective side of things. If you need a place to start looking, however, "Static Analysis for C#" is probably the best place.