C# IDisposable, Dispose(), lock (this)

1) Here I have a first question, how is this possible? After all, GC CLR destroys the object as correctly noticed when there are no more links to it. But if there are no references, how then can simultaneously still work the method of an object (Dispose()) to which nothing else refers? Yes, there are no links, but the method is not completed and GC CLR will try to delete the method object that still works?

Imagine that you have a method like:

void SomeMethod()
{
    var unmanagedPtr = this.MyPointer;
    while (/* some long loop */)
    {
        // lots of code that *just* uses unmanagedPtr
    }
}

Now; this here is arg0, so does exist in the stack, but the GC is allowed to look at when locals are read, and arg0 is not read past the first few instructions; so from the perspective of GC, it can ignore arg0 if the thread is in the while loop. Now; imagine that somehow the reference to this object only exists in arg0 - perhaps because it was only ever transient on the stack, i.e.

new MyType(...).SomeMethod();

At this point, yes, the object can be collected even though a method is executing on it. In most scenarios, we would never notice any side effect from this, but: finalizers and unmanaged data is a bit of a special case, beause if your finalizer invalidates the unmanagedPtr that the while loop is depending on: bad things.

The most appropriate fix here, is probably to just add GC.KeepAlive(this) to the end of SomeMethod. Importantly, note that GC.KeepAlive does literally nothing - it is an opaque, no-op, non-inlineable method, nothing else. All we're actually doing by adding GC.KeepAlive(this) is adding a read against arg0, which means that the GC needs to look at arg0, so it notices that the object is still reachable, and doesn't get collected.

2) Which in the proposed last solution will not allow GC CLR to call the this.Dispose(false) method in its thread in parallel through the destructor in the same way as before while this.Dispose(true) will still be executed previously launched explicitly?

For us to be able to call Dispose(), we clearly have a reference, so that's good. So we know it was reachable at least until Dispose, and we're only talking about Dispose(true) competing with Dispose(false). In this scenario, the GC.SuppressFinalize(this) serves two purposes:

• the mere existence of GC.SuppressFinalize(this) acts the same as GC.KeepAlive and marks the object as reachable; it can't possibly be collected until that point is reached
• and once it has been reached, it won't get finalized at all