none
Properly Dispose'ing an object (manually) RRS feed

  • Question

  • Greetings,

    I have a high-performance application (C# .Net 3.5) that creates thousands of objects per second -- to prevent latencies from the garbage collector, I want my class (that is instantiated thousands of times) to implement IDisposable, so I can manually dispose these objects, however I want to make sure I'm doing this correctly.

    public class DecodedMessage : IDisposable
    {
        protected Dictionary<int, object> values = new Dictionary<int, object>();
        protected bool disposed = false;
    
            public void Dispose()
            {
                Dispose(true);
                GC.SuppressFinalize(this);
            }
            protected void Dispose(bool disposing)
            {
                if (!disposed) {
                    if (disposing) {
                        // what to do here?
                    }
                    disposed = true;
                }
            }
            ~ DecodedMessage()
            {
                Dispose(false);
            }
    }


    This particular class (DecodedMessage) has one member variable, which is a Dictionary<int, object>, and so I'm not entirely sure what (if anything) needs to be done to this dictionary such that I can manually release these managed objects that exist within the dictionary.  The values in the dictionary will be either strings, ints, doubles, chars, or additional Dictionary<int, object> objects.

    I'm just a beginner with using the IDisposable framework, so any advice is greatly appreciated.

    Rick
    Wednesday, June 17, 2009 2:33 PM

Answers

  • You don't need to do anything.  Dictionary<TKey, TValue> is a fully managed, non-disposable class. There's no need to dispose it or anything in your class.  You can feel safe not implementing IDisposable at all here.  IDisposable need only be implemented by classes that use unmanaged resources, which yours doesn't. 

    The Garbage Collector is quite good.  I wouldn't worry about it unless you're having some problem that you're sure can be traced back to garbage collection.  Releasing managed objects is as simple as not holding a reference to them in your code.  Once the object that contains these objects detects that they're no longer accessible to your call stack, the GC will mark them for collection, and then collect them.
    David Morton - http://blog.davemorton.net/ - @davidmmorton - ForumsBrowser, a WPF Forums Client
    Wednesday, June 17, 2009 2:38 PM
    Moderator

All replies

  • You don't need to do anything.  Dictionary<TKey, TValue> is a fully managed, non-disposable class. There's no need to dispose it or anything in your class.  You can feel safe not implementing IDisposable at all here.  IDisposable need only be implemented by classes that use unmanaged resources, which yours doesn't. 

    The Garbage Collector is quite good.  I wouldn't worry about it unless you're having some problem that you're sure can be traced back to garbage collection.  Releasing managed objects is as simple as not holding a reference to them in your code.  Once the object that contains these objects detects that they're no longer accessible to your call stack, the GC will mark them for collection, and then collect them.
    David Morton - http://blog.davemorton.net/ - @davidmmorton - ForumsBrowser, a WPF Forums Client
    Wednesday, June 17, 2009 2:38 PM
    Moderator
  • What David says is entirely correct.

    I'm just going to add that disposing an IDisposable object does not free its memory. It just frees any resources that are held (file handles, etc). Memory is only freed by the GC.

           -Steve
    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
    MSBuild user? Try out the DynamicExecute task in the MSBuild Extension Pack source; it's currently in Beta so get your comments in!
    Wednesday, June 17, 2009 2:42 PM
  • David,

    Thanks.  I have been able to correlate queues in market data (this is a trading application) with garbage collection, and even a 5 millisecond delay can be a huge deal in this type of an application.  What I would like to do is basically have the GC do nothing -- is there any way to achieve this with managed objects?

    I should clarify that I'm not seeing "memory leaks" -- in other words, I'm releasing references to objects as I should be.  I simply would like to essentially do the work of the GC, if possible.

    Thanks again.

    Rick
    Wednesday, June 17, 2009 2:42 PM
  • If you want to do the work of the GC yourself, you're probably in the wrong language.  You might want to look into unmanaged C++ or something instead. 


    David Morton - http://blog.davemorton.net/ - @davidmmorton - ForumsBrowser, a WPF Forums Client
    Wednesday, June 17, 2009 2:44 PM
    Moderator
  • To follow up (again), if your requirements are really 5 ms, you're probably in the wrong OS. You'll need a RTOS, writing in C or assembler to achieve that level of accuracy reliably.

    Take a step back. No Windows application has a hard realtime requirement of 5ms; even device drivers can't guarantee this. I recommend you implement a trial solution to see if it's feasable to meet your requirements with managed code.

    Generally speaking (on a carefully tuned Windows Server box), you can provide 10ms pretty reliably. But there's no guarantee, ever.

           -Steve
    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
    MSBuild user? Try out the DynamicExecute task in the MSBuild Extension Pack source; it's currently in Beta so get your comments in!
    Wednesday, June 17, 2009 2:52 PM
  • Rick, you cannot prevent the GC from running however you can choose to get notified when it runs so you don't get any new work and that can be done using GC notifications - http://msdn.microsoft.com/en-us/library/system.gc.registerforfullgcnotification.aspx. Since you're mentioning this is a high performance application I'm assuming you have a server farm, in which case you can implement a mechanism to dispatch work in combinations with GC notifications - the worker will signal the dispatcher when it's about to do a GC and the dispatcher will not send any more work until the worker comes back and says GC is done.

    Wednesday, June 17, 2009 3:40 PM