<div>I know this question isn't a Mono-question per-se. However, it's a .NET implementation topic, and I can't think of a better place to get a well informed opinion. </div><div><br></div><div>In this 2005 article on the reason for the .NET v2.0 SafeHandle construct a GC finalizer race conditions is discussed. </div>

<div><br></div><a href="http://blogs.msdn.com/b/bclteam/archive/2005/03/16/396900.aspx">http://blogs.msdn.com/b/bclteam/archive/2005/03/16/396900.aspx</a>
<div><br></div><div>If I understand it correctly, it explains that a call to an instance method does not hold a GC reference to a "this" pointer for the duration of the call. Thus it is possible for an object instance to be GC finalized in one thread, while another thread still has code running inside the instance method -- if that instance method has no more references to it's "this" pointer. </div>

<div><br></div><div>This presents a particular problem for methods with calls to PInvoke entry points, as the thread may be inside unmanaged code using a resource when the Finalizer closes that unmanaged resource.</div><div>

<br></div><div>My questions are:</div><div><br></div><div>(1) Why would a call to an instance method not hold "this" alive for the entire duration of the call? </div><div><br></div><div>It seems this could happen in more cases than just PInvoke. This seems to allow a finalizer to run before an object is "done being used" anytime the object instance is not stored. (i.e. inside a statement of the form "new Foo().Method();") If the finalizer triggers an IDispose pattern, this could cause a managed resource to be torn down before it's done being used as well.</div>

<div><br></div><div>Why isn't this considered a bug in the .NET runtime?
</div><div><br></div><div>(2) Does the Mono GC have the same behavior?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>