开发者

Best way to prevent early garbage collection in CLR

开发者 https://www.devze.com 2022-12-28 15:26 出处:网络
I have written a managed class that wraps around an unmanaged C++ object, but I found that - when using it in C# - the GC kicks in early while I\'m executing a method on the object. I have read up on

I have written a managed class that wraps around an unmanaged C++ object, but I found that - when using it in C# - the GC kicks in early while I'm executing a method on the object. I have read up on garbage collection and how to prevent it from happening early. One way is to use a "using" statement to control when the object is disposed, but this 开发者_开发百科puts the responsibility on the client of the managed object. I could add to the managed class:

MyManagedObject::MyMethod() {

System::Runtime::InteropServices::GCHandle handle =
   System::Runtime::InteropServices::GCHandle::Alloc(this);

// access unmanaged member

handle.Free();

}

This appears to work. Being new to .NET, how do other people deal with this problem?

Thank you,

Johan


You might like to take a look at this article: http://www.codeproject.com/Tips/246372/Premature-NET-garbage-collection-or-Dude-wheres-my. I believe it describes your situation exactly. In short, the remedies are either ausing block or a GC.KeepAlive. However, I agree that in many cases you will not wish to pass this burden onto the client of the unmanaged object; in this case, a call to GC.KeepAlive(this) at the end of every wrapper method is a good solution.


You can use GC.KeepAlive(this) in your method's body if you want to keep the finalizer from being called. As others noted correctly in the comments, if your this reference is not live during the method call, it is possible for the finalizer to be called and for memory to be reclaimed during the call.

See http://blogs.microsoft.co.il/blogs/sasha/archive/2008/07/28/finalizer-vs-application-a-race-condition-from-hell.aspx for a detailed case study.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号