Notes about “directions” in software development

June 17, 2007
  • When doing software development the safest approach is to start the first with vertical design and development (up-down fits better agila and use-case driven development) and then elaborate on horizontal tiers as required.
  • When doing error handling in an application the best approach is from outside to inside. The first have generic error handling wrapping around topmost process and go inside process routines and wrap and handle as reqiuired.

More about GC, Dispose and Finalize

June 17, 2007

I see questions regarding the GC on a daily basis. Finalize vs. Dispose is a popular topic. Let’s get it in the clear.
All of us .NET programmers make use of the Garbage Collector (GC) – some without knowing so. You have to familiarize yourself with the internals of the GC if you wish to create scalable components – there is no other option. Even though it does all its bits automagically, you can harness a lot of its power by understanding three basics: Finalize, Dispose, and the Destructor protocol in managed code. I will not be going into the finer details of how the GC does its job, but rather explain how you as a programmer can (and should) optimize your objects for the GC.
Finalize
When an object is instantiated, the GC allocates memory for it on the managed heap. If the class contains a Finalize method, the object is also enlisted in the “finalisation queue”. When this object is no longer needed, its memory will be reclaimed (freed) by the GC. If the object is enlisted in the finalization queue, its Finalize method will be called before discarding of the object. The purpose of the Finalize method is to release any resources (like a database connection, or a handle on a window) that might be in use by your object.
Since the GC decides when it is best to clean up objects (and it does a damn fine job in doing so!), you have no way of telling when exactly Finalize will be called. Finalize is also a protected member and can thus not be called explicitly. Does this mean that cleaning up your object is left entirely in the hands of the GC?
Dispose
Of course not. For increased performance, it is best to cleanup your unused resources immediately after using them. For instance, as soon as you have retrieved your data through a database connection, the connection should be discarded of since it eats up system resources like memory, which could be better utilized by objects that you do in fact need. For this reason, an object can implement the Dispose method (by implementing the IDisposable interface). Calling the Dispose method on an object does two things. Firstly, it cleans up any resources that were in use by your object. Secondly, it marks the object so that the GC would not call its Finalize method when it collects it – the resources have been cleaned up already in your Dispose method. This way, you save the overhead of the GC’s call to Finalize, and you can clean up your object at the most appropriate time.
How to implement Finalize and Dispose
Now that you know the reasons for these two methods, let’s see how to implement it.
In managed code, you cannot override or even call Finalize – it is implicitly generated (in IL) by the compiler if you have a destructor for your object. In other words, the following:

~MyClass
{
//Cleanup code here
}
Translates to the following:
protected override void Finalize()
{
try
{
//Cleanup of used resources
}
finally
{
base.Finalize();
}
}

As you can see, the method also calls Finalize on its parent type, and the parent type will call Finalize on its parent type – the whole hierarchy of your object is thus cleaned up. It is important to understand that you should only have a destructor for your class if it is really necessary, since calling Finalize, and enlisting objects that implement Finalize in the finalization queue by the GC, has significant performance implications.
The Dispose method is publicly callable. (I’ll explain the overload that accepts the boolean parameter later). Here is an example of an object that implements IDisposable:

public class MyClass : IDisposable, BaseClass
{
bool disposed; //Indicates if object has been disposed
//Constructor, where your resources might be instantiated
public MyClass()
{
disposed = false;
//Other Constructor code here
}

//Destructor, that would imply a Finalize method as noted above
~MyClass()
{
//Dispose is called, passing false, so that only
//unmanaged resources are cleaned up.
Dispose(false);
}

public void Dispose()
{
Dispose(true);
//Prevent the GC to call Finalize again, since you have already
//cleaned up.
GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
//Make sure Dispose does not get called more than once,
//by checking the disposed field
try
{
if (!this.disposed)
{
if (disposing)
{
//Clean up managed resources
}
//Now clean up unmanaged resources
}
disposed = true;
}
finally
{
base.Dispose(disposing);
}
}
}

When you explicitly call Dispose() on your object, both managed- and unmanaged resources will be cleaned up. When the GC cleans your object (instead of you), only unmanaged resources will be cleaned, since the managed resources will be cleaned up by the GC when necessary.
Final Notes
Don’t reference any managed resources in your Finalize method (destructor), since Finalizers are not called in any particular fashion, and the object you reference may thus be disposed of already. In such a case, your Finalize method will fail. If you *do* reference any managed resources downward in your object hierarchy, those objects will not be finalized with the current GC collection, and performance will suffer.
When calling any method on your object, it is necessary to first check if the object has been disposed. So a method in MyClass would look like this:
//In MyClass:

public void MyMethod()
{
if (this.disposed)
{
throw new ObjectDisposedException();
}
//Method code goes here
}

In a further article, I will dive deeper into the GC, and explain the implications of threading on your Finalize and Dispose methods.

In GC 101, I discussed the reasons for Finalize and Dispose, and how to implement these methods in your components. The C# language has some nice built-in functionality to help you with the Disposing pattern, which I will discuss here.
Cool C# feature: using
Consider the following code:
SqlConnection cn = new SqlConnection(cnString);
cn.Open();
//Use the open connection
cn.Dispose();
If an exception had to be thrown on the call to Open, Dispose will never get called, and your resource might leak. I’m sure you already know the solution:

try
{
SqlConnection cn = new SqlConnection(cnString);
cn.Open();
//Use the open connection
}
finally
{
cn.Dispose();
}

This code does exactly what the first listing does, but is safer – you are guaranteed that Dispose will be called. But, it is also much less readable! C# has a nice feature to help with readability here: the using clause. Our code can be rewritten as:

using (SqlConnection cn = new SqlConnection(cnString))
{
cn.Open();
//Use the open connection
}

Lovely, isn’t it? As soon as the using block exits, Dispose will automatically be called on all objects that implement IDisposable and are created with the using-clause. If you look at the compiler-generated IL, you will see that a try – finally is actually implemented.
Cool C# feature: foreach
You might have collections of expensive (disposable) objects from time to time. To ease coding against your collection, have it implement IDisposable:

internal class openDBConnectionsEnumerator : IEnumerator, IDisposable
{}
public class openDBConnections : IEnumerable
{
public IEnumerator GetEnumerator()
{
return new openDBConnectionsEnumerator();
}
}

Now, you can use your collection in a foreach loop, and Dispose is called automatically on your collection when the loop exits:

OpenDBConnections cons = new OpenDBConnections();
foreach(DBConnection in cons)
{
//Do something with connection object
} //Dispose is called on the IEnumerator when loop exits

Performance issues

The GC has only one thread that calls Finalize on all the objects in the finalization queue, and thus might have a tough time in keeping up with Finalizable objects created by more than one user thread. A shortened overview of a Finalizable object’s lifespan:

There are actions here that impacts negatively on performance:
1. Enlisting in the Finalization queue
2. Removing from Finalization queue to be enlisted in To Be Finalized queue
3. Calling Finalize on the component
4. Removing from To Be Finalized queue
It should be obvious that, if possible, the shortcut should be taken, and Finalizable components avoided. To do so, and this is quite important:
1. Don’t create Finalizers (or destructors) for your components unless absolutely necessary.
2. For components where you do need a destructor, always call Dispose on your component when appropriate. This suppresses the GC’s call to Finalize and saves you the overhead of calling Finalize and enlisting in the To Be Finalized queue.
Threading
A component’s Dispose(bool) method should never be called from both the GC’s finalizer thread and a user thread. There may be instances where more than one user thread calls the method. In this case, make your cleanup code thread safe in exactly the same way you’d make any code thread safe. If you are 100% sure that your code will not be called by more than one user thread at a time, don’t enforce thread-safety, as this impacts negatively on performance.
(You will also find this article on my blog).

Dispose, Part 3
Can I just let the GC get everything? When do I have to worry about Dispose?

If the object implements IDisposable then you should think about how the object is getting cleaned up.

Objects that implement IDisposable usually do so because they are holding on to real resources that should be freed deterministically. Rule of thumb:
If the object implements IDisposable then you should think about how the object is getting cleaned up.

When a control is disposed, it disposes all of its children. The only time you get automagic disposal of controls is when you do Application.Run(new Form()). (We like to call this showing the form modelessly). When the form gets WM_CLOSE message, it starts cleaning itself up while it can.

However if you do a Form.ShowDialog(), the form is NOT disposed. (We like to call this showing the form modally). This is because you may want to go in after the form has closed and look at the state of the child controls to determine the next action of your program.

If you add and remove controls from your form dynamically, you should call dispose on them – otherwise you’ll accumulate extra unwanted window handles in your process. Remember you only have to dispose the topmost control – so if you’re swapping in and out a panel – disposing the panel disposes it’s child controls.

Dispose is not just for controls though – Brushes, Pens, and Fonts implement IDisposable as well. These hold onto GDI objects, not window handles. If you leak these objects, it can cause quite a perf problem in your application as System.Drawing may start to GC extra times to get the number of handles back in check. SystemPens and SystemBrushes do not need to be disposed – these are cached objects. SystemFonts do as they are a live fetch from the OS of the current MenuFont etc.

However, if you are creating a new control that holds onto its own IDisposable object (e.g. it’s own tooltip), that control should override Dispose(bool disposing) and add calls to Dispose() for these objects.

If you are concerned about a leak in your code – bring up task manager, switch to processes. View->Select Columns and tick off USER objects and GDI objects. This should show you the live count of how many handles you have out.


http://msdn2.microsoft.com/en-us/3bwa4xa9.aspx

.NET Framework Developer’s Guide
Using Objects That Encapsulate Resources
When you write code that uses an object that encapsulates a resource, you should make sure that the object’s Dispose method gets called when you are finished using the object. You can do this with the C# using statement or by implementing a try/finally block in other languages that target the common language runtime.
C# Using Statement
The C# programming language’s using statement makes a call to the Dispose method more automatic, by simplifying the code that you must write to create and clean up an object. The using statement obtains one or more resources, executes the statements that you specify, and then disposes of the object. Note that the using statement is only useful for objects with a lifetime that does not extend beyond the method in which the objects are constructed. The following code example creates and cleans up an instance of the ResourceWrapper class, as illustrated in the C# example of implementing a Dispose method.

class myApp
{
public static void Main()
{
using (ResourceWrapper r1 = new ResourceWrapper())
{
// Do something with the object.
r1.DoSomething();
}
}
}

The preceding code, incorporating the using statement, is equivalent to the following.


class myApp
{
public static void Main()
{
ResourceWrapper r1 = new ResourceWrapper();
try
{
// Do something with the object.
r1.DoSomething();
}
finally
{
// Check for a null resource.
if (r1 != null)
// Call the object's Dispose method.
r1.Dispose();
}
}
}

The C# using statement allows you to acquire multiple resources in a single statement, which is equivalent internally to nested using statements. For more information and a code example, see using Statement (C# Reference).
Try/Finally Block
When you write managed code that uses an object that encapsulates a resource in languages other than C#, use a try/finally block to ensure that a call is made to the object’s Dispose method. The following code example creates and cleans up an instance of the Resource class, as illustrated in the Visual Basic example of implementing a Dispose method.


class myApp
Public Shared Sub Main()
Resource r1 = new Resource()
Try
' Do something with the object.
r1.DoSomething()
Finally
' Check for a null resource.
If Not (r1 is Nothing) Then
' Call the object's Dispose method.
r1.Dispose()
End If
End Try
End Sub
End Class

.NET Framework Developer’s Guide
Cleaning Up Unmanaged Resources

http://msdn2.microsoft.com/en-us/498928w2.aspx

You should prevent users of your application from calling an object’s Finalize method directly by limiting its scope to protected. In addition, you are strongly discouraged from calling a Finalize method for a class other than your base class directly from your application’s code. To properly dispose of unmanaged resources, it is recommended that you implement a public Dispose or Close method that executes the necessary cleanup code for the object. The IDisposable interface provides the Dispose method for resource classes that implement the interface. Because it is public, users of your application can call the Dispose method directly to free memory used by unmanaged resources. When you properly implement a Dispose method, the Finalize method becomes a safeguard to clean up resources in the event that the Dispose method is not called. For more information on correct implementation, see Implementing a Dispose Method.

A Finalize method acts as a safeguard to clean up resources in the event that your Dispose method is not called. You should only implement a Finalize method to clean up unmanaged resources. You should not implement a Finalize method for managed objects, because the garbage collector cleans up managed resources automatically. By default, the Object.Finalize method does nothing. If you want the garbage collector to perform cleanup operations on your object before it reclaims the object’s memory, you must override this method in your class.


Thread Safety

June 17, 2007

Collection Thread Safety

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

This implementation does not provide a synchronized (thread safe) wrapper for a CollectionBase, but derived classes can create their own synchronized versions of the CollectionBase using the SyncRoot property.

Enumerating through a collection is intrinsically not a thread safe procedure. Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

http://msdn2.microsoft.com/en-us/library/system.collections.collectionbase(VS.80).aspx


Martin Niemoeller

June 17, 2007

First they came for the Communists, but I was not a Communist so I did not speak out. Then they came for the Socialists and the Trade Unionists, but I was neither, so I did not speak out. Then they came for the Jews, but I was not a Jew so I did not speak out. And when they came for me, there was no one left to speak out for me.”


.NET CLR optimization good practices

February 3, 2007

GC

  • free your object as soon as possible (this will help to prevent the object promotion to into higher GC generation)
  • long lived object create early (this will help to avoid memory defragmentation by setting long lived (promoted to 1 and 2) object at bottom of CLR memory block) Read the rest of this entry »

Threads…and multitasking illusion

February 3, 2007

Today software development platforms have so many layers of abstractions around CPU machine code in order to help software developers to focus more on domain implementation problems (business, scientific …) and solutions.
The fact is that a software designer and developer depends on so many lines of code that somebody else has designed. We utilize in our applications the hundreds of code libraries and most times we only know about (API or object based) their interfaces and the rest is just a black box. Read the rest of this entry »


.NET Generics for generic solutions

February 3, 2007

What are the generics in .NET 2.0 ?

There are many ways to define it, like:
Generic types and methods <=> parametric polymorphism,
Generic types and methods <=> parametrized types

Anyway generics with interfaces are the all you need for a generic solution for your subsytem…and some VB, C# and pattern knowledge. Read the rest of this entry »