I have an object that is expensive to create, which uses some unmanaged resources that must be explicitly freed when done with and so implement IDisposable(). I would like a cache for instance of these expensive resources so that the creation cost is minimized, but I am having trouble knowing how to deal with the disposal.
If the methods that use the objects are responsible for the disposal then I end up with disposed instances in the cache, which then have to be recreated, defeating the point of the cache. If I don't dispose the objects in the methods that use them then they never get disposed. I thought I could dispose them when they are taken out of the cache, but then I might end up disposing an instance which is still being used by a method.
Is it valid to just let them go out of scope and be collected by the garbage collector and free up the resources at that point? This feels wrong and against the idea of them being disposable...
First of all, the type that wraps the native resources should be finalizable, not just disposable. Even better, use SafeHandle to wrap the native resources.
Unless someone is explicitly responsible for saying they are done with the item and it can be disposed, then I think you're better off letting the GC take care of it. Note that it must be finalizable though, otherwise the GC won't give it a second glance.
An object should be disposed by the class that creates it. Since your callers have not created the items in the cache, they have no business disposing of them, either.
I'd want to make sure that your factory method is named something like "GetClass" rather than "CreateClass" in order to emphasize that the caller is not responsible for creation, and therefore not for disposal.
To (mis-)quote Raymond Chen: Every cache without an expiration policy is a leak
So, set a clear cache expiration policy, and let the cache dispose them as the normal case. This still leaves application shutdown to be handled.
If your unmanaged ressources are owned by the process, you can let the process release them on shutdown.
If the unmanaged ressources are not owned by the process, you need to detect shutdown and explicitely Dispose the cached elements.
If you can't detect process shutdown reliably, and the managed ressources are expensive, the unmanaged ones are not, separate the managed from the unmanaged ressources, and let the cache keep only the managed ones.
When the unmanaged ressources are expensive so they need caching, and they are not owned by the process, and you cannot detect process shutdown reliably and you cannot afford to leak them, then your problem cannot be solved.
Disposable objects always need to have a clear owner who is responsible for disposing them. However, this is not always the object that created them. Furthermore, ownership can be transferred.
Realizing this, the solution becomes obvious. Don't dispose, recycle! You need not only a way to acquire a resource from the cache, but also a way to return it. At that point the cache is owner again, and can choose to retain the resource for future use or to dispose it.
edit: I just noticed that this idea also exists in Spring, where it is called an object pool. Their
BorrowObject
andReturnObject
methods match the methods in my example.You can solve this with a class factory and IDisposable. For example:
You could decouple the unmanaged resources from the managed instance and use a cache manager to hold a set of unmanaged resources. The managed object will try to acquire an instance of the unmanaged resource from the cache manager which will either create one or give one free instance from the cache and return it to the cache manager (instead of disposing it itself) at the time of its disposal. The cache manager will be the sole responsible object for allocating and freeing unmanaged resources when it sees it's necessary.