IDisposable + finalizer pattern - garbage-collection

Question

Looking at the IDisposable pattern + Finalizer pattern, there is something I don't understand:
public class ComplexCleanupBase : IDisposable
{
private bool disposed = false; // to detect redundant calls
public ComplexCleanupBase()
{
// allocate resources
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// dispose-only, i.e. non-finalizable logic
}
// shared cleanup logic
disposed = true;
}
}
~ComplexCleanupBase()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
From my understanding the pattern should be implemented like above.
1) Calling Dispose() fires GC.SuppressFinalize(this), which means that the object should not be put on the finalizer queue as its already properly disposed? That helps to free up the object faster?
2) But what if I am not calling Dispose() on this object at all? In that case the finalizer should kick in, correct? But Dispose(false); does absolutely nothing (only setting disposed = true). Is this intended? It feels like as if something is missing...

Answer 1

Question 1: Yes, if GC.SuppressFinalize is not called the object will be placed on the finalizer queue AND will move up a generation (if not already gen 2), which means that the memory for that object will not be reclaimed until the next pass of GC for the new generation.
Question 2: Your comment //shared cleanup logic is where the shared cleanup logic will go, this is where things other than setting disposed = true would happen.
Also, an aside: if your dispose logic should only be called once, consider acquiring a lock, an uncontested lock is very fast in .Net:
public class ComplexCleanupBase : IDisposable
{
private volatile bool disposed = false; // to detect redundant calls
private readonly object _mutex = new object();
protected virtual void Dispose(bool disposing)
{
if (!Monitor.TryEnter(_mutex))
{
// We're already being disposed.
return;
}
try
{
if (!disposed)
{
if (disposing)
{
// dispose-only, i.e. non-finalizable logic
}
// shared cleanup logic
disposed = true;
}
}
finally
{
Monitor.Exit(_mutex);
}
}
... other methods unchanged
}

Answer 2

If Dispose(false) isn't going to do anything, that's a very good indication that neither your class nor any class derived from it should include a C#-style "destructor" nor override Finalize, and the "disposing" argument should be regarded as a dummy whose purpose is to give the protected Dispose method a different signature from the public one.
Note that implementing a destructor or overriding Finalize in a derived class, when the parent class is not expecting such behavior, can produce Heisenbugs. Among other things, the GC can sometimes decide that a class object has been abandoned, triggering its finalizer/destructor, even while an entity referred to by a field of the class is being used. For example, suppose a static class usbThingie manipulates USB controllers using integer handles, and a wrapper class usbWrapper does something like:
UInt32 myHandle;
void sendData(Byte data[])
{
UsbThingie.send(myHandle, data[0], data.Length);
}
If a sendData() call is the last thing done to an instance of usbWrapper before it is abandoned, it would be possible for the garbage-collector to observe that once UsbThingie.send() is called--even before it returns--no further references will exist to the usbWrapper, and thus it can safely trigger the finalizer. If the finalizer tries to close the channel referred to by myHandle, that might disrupt the transmission that was taking place; if usbThingie isn't thread-safe, there's no telling what might happen.