1

I have a couple of unmanaged memory structures used to communicate with c++ dlls. Each such structure has to be freed manually, so I wrap it in a MyUnmanagedStructure which implements IDisposable.

I always need a variable number of these structures together, so I have a collection MyUnmanagedStructureCollection which also implements IDisposable.

(see below for the minimal example code)

As long as the user of my library always calls Dispose() or wraps the collection with using() {} there is no problem, but I cannot assure that. I do not want to leak memory even if the user does not dispose the collection manually.

When the MyUnmanagedStructureCollection.Dispose() method is called by the garbage collection via finalizer instead, then as far as I understand I cannot be sure that my private List<MyUnmanagedStructure> has not been garbage collected already, so how can I dispose of each structure in that case?

In my finalizing code, should I attempt to iterate over the list, hoping that it has not been garbage collected yet?

Is it good practise to do this in a try/catch block, catching ObjectDisposedException?

Or should I let each unmanagedStructure "fend for itself", relying on the individual finalizers, and simply do nothing in the finalizer of my collection?

public class MyUnmanagedStructureCollection : IDisposable
{
    private List<MyUnmanagedStructure> structures;
    private bool disposed = false;

    #region standard IDIsposable pattern
    public ~MyUnmanagedStructureCollection()
    {
        this.Dispose(false);
    }

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

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            // Dispose unmanaged resources 
            // Should not access managed resources, 
            // the garbage collection may have claimed them already!

            // PROBLEM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
            // this.structures is a List<MyUnmanagedStructure>; so is a managed resource!!!

            foreach (var structure in this.structures)
                 structure.Dispose(disposing)
            this.removeAllMemoryPressure();

            if (disposing) 
            {
                // Dispose managed resources.
                this.structures.Clear();
                this.structures = null;
            }

        }
        disposed = true;
    }
}


public class MyUnmanagedBuffer : IDisposable
{
...
}
HugoRune
  • 13,157
  • 7
  • 69
  • 144
  • 1
    How could the list be collected when its still referenced from your object? It's just that the objects in the collection might have been finalized(but not collected) already. – CodesInChaos Aug 27 '12 at 13:08
  • Well, my object and the List inside the object will be collected together, and as far as I understand, the GC does not guarantee in which order it will destroy them. I might be wrong though – HugoRune Aug 27 '12 at 13:09
  • The GC does not guarantee the order of *finalization*. It guarantees that any object thats reachable from a finalizer has not been collected yet. – CodesInChaos Aug 27 '12 at 13:12
  • My worries stem form the common advice I have read about the IDisposable pattern, for example [here](http://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface). Everything I read claims I should not access managed objects from my finalizer. Is it really save to access a managed List from my finalizer? – HugoRune Aug 27 '12 at 13:16
  • The finalizer of your collection just adds unnecessary overhead. The finalizers of the elements already get the job done. With the additional risk of finalizing an element that was already finalized. Just remove the collection finalizer, it doesn't help anything. – Hans Passant Aug 27 '12 at 13:32
  • Well, I may have simplified my example too much. The collection also manages a different unmanaged resource, not in the list, that needs to be freed. It also needs to call GC.RemoveMemoryPressure() to remove the amount of MemoryPressure that was added during the creation of the collection – HugoRune Aug 27 '12 at 13:43

2 Answers2

2

The way the GC works is:

  1. Find all reachable objects
  2. Enqueue all unreachable objects with a finalizer into the finalization queue
  3. Mark all objects that are reachable from from the finalization queue as reachable
  4. Free the remaining unreachable objects

An object that's referenced from an object whose finalizer is running cannot have been garbage collected yet.

The only thing you need to be careful about is that the order of finalization is undefined. So the elements of the list might have been finalized yet, but not collected. Finalization is guaranteed to be single threaded, so you need locking too.

One generally tries to avoid such finalization chains, since independent finalization is simpler. But if some objects need to be disposed before others, such a construction is unavoidable.

You should also consider critical finalization using SafeHandles.


Reachability

One of the guidelines for finalization is that a Finalize method shouldn't touch other objects. People sometimes incorrectly assume that this is because those other objects have already been collected. Yet, as I have explained, the entire reachable graph from a finalizable object is promoted.

The real reason for the guideline is to avoid touching objects that may have already been finalized. That's because finalization is unordered.

Chris Brumme on finalization

Community
  • 1
  • 1
CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • My worries stem form the common advice I have read about the IDisposable pattern, for example [here](http://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface). Everything I read claims I should not access managed objects from my finalizer. Is it really save to access a managed List from my finalizer? – HugoRune Aug 27 '12 at 13:17
  • Thanks a lot, your update clears that question up nicely. Regarding your suggestion of SafeHandle, I read about them but so far I could not figure out how to use them, since the code to create this unmanaged object is inside the C-Dll, and I only get a pointer on the C# side (and I have to call a function in the C-Dll with this pointer to free it at the end) – HugoRune Aug 27 '12 at 13:31
  • Minor technical nit: for whatever reason, the name of the list of objects that have registered finalizers but are *not* tagged for immediate finalization is the "finalization queue". The list of objects that have been found to be unreachable is the "freachable" queue. (information from http://msdn.microsoft.com/en-us/magazine/bb985010.aspx ). The names seem backward, but as far as I can tell that site is correct. – supercat Aug 27 '12 at 19:42
1

Since you're MyUnmanagedBuffer class is a managed resource from point-of-view of your MyUnmanagedStructureCollection class, I think it should handle it as such. This would mean that the MyUnmanagedStructureCollection.Dispose(bool) method would be as below.

protected virtual void Dispose(bool disposing) {
    if (!disposed) {
        // Dispose unmanaged resources 
        // Should not access managed resources, 
        // the garbage collection may have claimed them already!

        if (disposing) {
            // Dispose managed resources.
            // This means that we try to dispose all items in the structures collection.
            if (this.structures != null) {
                foreach (var structure in this.structures) {
                    structure.Dispose(disposing);
                    this.removeAllMemoryPressure(); // What does this?
                }
                this.structures.Clear();
                this.structures = null;
            }
        }
    }

    disposed = true;
}
Maarten
  • 22,527
  • 3
  • 47
  • 68
  • removeAllMemoryPressure() calls `GC.RemoveMemoryPressure(this.memoryPressure)`, I was not sure I should mention that in the example. Whenever I add an UnmanagedStructure, i call GC.AddMemoryPressure(SizeOfStructure) to make GC take that size into account. So I need to remove the exact same amount of memoryPressure at the end, no matter how my class is disposed – HugoRune Aug 27 '12 at 13:37