Reputation: 13789
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
{
...
}
Upvotes: 1
Views: 570
Reputation: 22945
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;
}
Upvotes: 1
Reputation: 108790
The way the GC works is:
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 SafeHandle
s.
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.
Upvotes: 2