Question

In answering another question* on SO, and the subsequent comment discussion, I ran into a wall on a point that I’m not clear on.

Correct me on any point where I’m astray…

When the Garbage Collector collects an object, it calls that object’s finalizer, on a separate thread (unless the finalizer has been suppressed, e.g. through a Dispose() method). While collecting, the GC suspends all threads except the thread that triggered the collection (background collection aside).

What isn’t clear:

1. Does the Garbage Collector wait for the finalizer to execute on that object before collecting it?
2. If not, does it un-suspend threads while the finalizer is still executing?
3. If it does wait, what happens if the finalizer runs into a lock being held by one of the suspended threads? Does the finalizer thread deadlock? (In my answer, I argue that this is bad design, but I could possibly see cases where this could happen)

* Link to the original question:
.NET GC Accessing a synchronised object from a finalizer

Answer 1

Does the Garbage Collector wait for the finalizer to execute on that object before collecting it?

Your question is a bit ambiguous.

When the GC encounters a “dead” object that needs finalization, it abandons its attempt to reclaim the dead object’s storage. Instead, it puts the object on a queue of “objects that I know need finalization” and treats that object as alive until the finalizer thread is done with it.

So, yes, the GC does “wait” until the finalizer is executed before reclaiming the storage. But it does not wait synchronously. It sounds like you’re asking “does the GC synchronously call the finalizer right there?” No, it queues up the object to be finalized later and keeps on truckin’. The GC wants to quickly get through the task of releasing garbage and compacting memory so that the program proper can resume running ASAP. It’s not going to stop to deal with some whiny object that is demanding attention before it gets cleaned up. It puts that object on a queue and says “be quiet and the finalizer thread will deal with you later.”

Later on the GC will check the object again and say “are you still dead? And has your finalizer run?” If the answer is “yes” then the object gets reclaimed. (Remember, a finalizer might make a dead object back into a live one; try to never do that. Nothing pleasant happens as a result.)

Does it un-suspend threads while the finalizer is still executing?

I believe that the GC thaws out the threads that it froze, and signals the finalizer thread “hey, you’ve got work to do”. So when the finalizer thread starts running, the threads that were frozen by the GC are starting up again.

There might have to be unfrozen threads because the finalizer might require a call to be marshalled to a user thread in order to release a thread-affinitized resource. Of course some of those user threads might be blocked or frozen; threads can always be blocked by something.

what happens if the finalizer runs into a lock being held by one of the suspended threads? Does the finalizer thread deadlock?

You betcha. There’s nothing magic about the finalizer thread that prevents it from deadlocking. If a user thread is waiting on a lock taken out by the finalizer thread, and the finalizer thread is waiting on a lock taken out by the user thread, then you’ve got a deadlock.

Examples of finalizer thread deadlocks abound. Here’s a good article on one such scenario, with a bunch of links to other scenarios:

http://blogs.microsoft.co.il/blogs/sasha/archive/2010/06/30/sta-objects-and-the-finalizer-thread-tale-of-a-deadlock.aspx

As the article states: finalizers are an extremely complex and dangerous cleanup mechanism and you should avoid them if you possibly can. It is incredibly easy to get a finalizer wrong and very hard to get it right.