Implementing Value Types – Best Practices

When implementing you own struct you should take into consideration the following:

  • Use structs when you intend to create a great many of them
  • structs should be small. Large structs (i.e. structs with many fields) would lead to poor performance, since structs are copied each time.
  • Use structs when you require high density memory collections.  Structs have have a much simpler memory layout and offer excellent memory density and lack of overhead
  • Override structs Equals(…) method and implement IEquitable<T> interface to  avoid boxing.
  • Overload == and != operators
  • Override GetHashCode method.
  • structs should almost always be immutable. Actually I’ll go further and say always. Mutable structs could lead to confusion if declared as readonly. Any modifications to a mutable readonly struct will be ignored, making it a very difficult bug to spot.

Structs have also got their own limitations. Since they don’t have an object header, you cannot for example use a lock(…) on a struct since this  will result on compile time error. However Monitor.Enter(…) accepts any object, structs included, thus leading to a bug. The value  of the struct will be boxed each time and that would be equivalent to having no lock at all!

Advertisements

Troubleshootng Deadlocks in .NET Applications

What do you do when your application become unresponsive due to potential deadlocks?

I think the first thing to do is to identify exactly where the application hangs due to a deadlock. To do this you should replace the lock(…) statement with it’s equivalent Monitor.Enter(…)/Monitor.Exit(…). Monitor has an argument which alloys you to specify timeout. So when you change the suspicious code with Monitor.Enter(…)/Monitor.Exit(…) while specifying the timeout, the code will throw the exception when this timeout has exceeded the specified timeout. While this doesn’t solve the dead lock issue, it points you to the location within you code where there is a possible issue.

Additionally, you need to make sure that the locks are taken in the same order i.e,

lock(_a)
{
     lock(_b)
    {
        ....
    } 
}

This is only for troubleshooting purposes. You should revert back to normal locking when the issue is found and fixed.

One easy thing you can do is to pause execution within Visual Studio by pressing on the pause button and then see what each thread is up to.

You also might want to consider more granular locking primitives, such ReadWriterLockerSlim and refactor you code to use less locking.

Whenever you feel like putting a lock always question yourself if this is the right thing to do and if there is a way doing this without locking all together

C# – Undocumented Keywords

While browsing the code of the interlocked class I stumbled upon the following piece of code

public static T CompareExchange<T>(ref T location1, T value, T comparand) where T : class
{
    // _CompareExchange() passes back the value read from location1 via local named 'value'
    _CompareExchange(__makeref(location1), __makeref(value), comparand);
    return value;
}

Further googling revealed that there are actually 4 undocumented keywords in C# __arglist, __refvalue, __makeref, __reftype

More on the subject can be found on codeproject: http://www.codeproject.com/Articles/38695/UnCommon-C-keywords-A-Look

Blog at WordPress.com.

Up ↑