Let's say I have a class that implements the IDisposable interface. Something like this:
MyClass uses some unmanaged resources, hence the Dispose() method from IDisposable releases those resources. MyClass should be used like this:
using ( MyClass myClass = new MyClass() ) {
myClass.DoSomething();
}
Now, I want to implement a method that calls DoSomething() asynchronously. I add a new method to MyClass:
Now, from the client side, MyClass should be used like this:
using ( MyClass myClass = new MyClass() ) {
myClass.AsyncDoSomething();
}
However, if I don't do anything else, this could fail as the object myClass might be disposed before DoSomething() is called (and throw an unexpected ObjectDisposedException). So, the call to the Dispose() method (either implicit or explicit) should be delayed until the asynchronous call to DoSomething() is done.
I think the code in the Dispose() method should be executed in a asynchronous way, and only once all asynchronous calls are resolved. I'd like to know which could be the best way to accomplish this.
Thanks.
NOTE: For the sake of simplicity, I haven't entered in the details of how Dispose() method is implemented. In real life I usually follow the Dispose pattern.
UPDATE: Thank you so much for your responses. I appreciate your effort. As chakrit has commented, I need that multiple calls to the async DoSomething can be made. Ideally, something like this should work fine:
using ( MyClass myClass = new MyClass() ) {
myClass.AsyncDoSomething();
myClass.AsyncDoSomething();
}
I'll study the counting semaphore, it seems what I'm looking for. It could also be a design problem. If I find it convenient, I will share with you some bits of the real case and what MyClass really does.
-
Async methods usually have a callback allowing you to do do some action upon completition. If this is your case it would be something like this:
// The async method taks an on-completed callback delegate myClass.AsyncDoSomething(delegate { myClass.Dispose(); });An other way around this is an async wrapper:
ThreadPool.QueueUserWorkItem(delegate { using(myClass) { // The class doesn't know about async operations, a helper method does that myClass.DoSomething(); } }); -
I wouldn't alter the code somehow to allow for async disposes. Instead I would make sure when the call to AsyncDoSomething is made, it will have a copy of all the data it needs to execute. That method should be responsible for cleaning up all if its resources.
-
It looks like you're using the event-based async pattern (see here for more info about .NET async patterns) so what you'd typically have is an event on the class that fires when the async operation is completed named
DoSomethingCompleted(note thatAsyncDoSomethingshould really be calledDoSomethingAsyncto follow the pattern correctly). With this event exposed you could write:var myClass = new MyClass(); myClass.DoSomethingCompleted += (sender, e) => myClass.Dispose(); myClass.DoSomethingAsync();The other alternative is to use the
IAsyncResultpattern, where you can pass a delegate that calls the dispose method to theAsyncCallbackparameter (more info on this pattern is in the page above too). In this case you'd haveBeginDoSomethingandEndDoSomethingmethods instead ofDoSomethingAsync, and would call it something like...var myClass = new MyClass(); myClass.BeginDoSomething( asyncResult => { using (myClass) { myClass.EndDoSomething(asyncResult); } }, null);But whichever way you do it, you need a way for the caller to be notified that the async operation has completed so it can dispose of the object at the correct time.
-
You could add a callback mechanism and pass a cleanup function as a callback.
var x = new MyClass(); Action cleanup = () => x.Dispose(); x.DoSomethingAsync(/*and then*/cleanup);but this would pose problem if you want to run multiple async calls off the same object instance.
One way would be to implement a simple counting semaphore with the Semaphore class to count the number of running async jobs.
Add the counter to MyClass and on every AsyncWhatever calls increment the counter, on exits decerement it. When the semaphore is 0, then the class is ready to be disposed.
var x = new MyClass(); x.DoSomethingAsync(); x.DoSomethingAsync2(); while (x.RunningJobsCount > 0) Thread.CurrentThread.Sleep(500); x.Dispose();But I doubt that would be the ideal way. I smell a design problem. Maybe a re-thought of MyClass designs could avoid this?
Could you share some bit of MyClass implementation? What it's supposed to do?
Nicholas Mancuso : Sleeping in a loop is considered bad practice. You should be using an EventWaitHandle to fire off an event upon finishing.Auron : Unfortunately, I'm limited to .NET CF 1.0, and the class Semaphore is only supported since .NET 2.0.chakrit : It's just an "example"... mind you. -
So, my idea is to keep how many AsyncDoSomething() are pending to complete, and only dispose when this count reaches to zero. My initial approach is:
public class MyClass : IDisposable { private delegate void AsyncDoSomethingCaller(); private delegate void AsyncDoDisposeCaller(); private int pendingTasks = 0; public DoSomething() { // Do whatever. } public AsyncDoSomething() { pendingTasks++; AsyncDoSomethingCaller caller = new AsyncDoSomethingCaller(); caller.BeginInvoke( new AsyncCallback( EndDoSomethingCallback ), caller); } public Dispose() { AsyncDoDisposeCaller caller = new AsyncDoDisposeCaller(); caller.BeginInvoke( new AsyncCallback( EndDoDisposeCallback ), caller); } private DoDispose() { WaitForPendingTasks(); // Finally, dispose whatever managed and unmanaged resources. } private void WaitForPendingTasks() { while ( true ) { // Check if there is a pending task. if ( pendingTasks == 0 ) { return; } // Allow other threads to execute. Thread.Sleep( 0 ); } } private void EndDoSomethingCallback( IAsyncResult ar ) { AsyncDoSomethingCaller caller = (AsyncDoSomethingCaller) ar.AsyncState; caller.EndInvoke( ar ); pendingTasks--; } private void EndDoDisposeCallback( IAsyncResult ar ) { AsyncDoDisposeCaller caller = (AsyncDoDisposeCaller) ar.AsyncState; caller.EndInvoke( ar ); } }Some issues may occur if two or more threads try to read / write the pendingTasks variable concurrently, so the lock keyword should be used to prevent race conditions:
public class MyClass : IDisposable { private delegate void AsyncDoSomethingCaller(); private delegate void AsyncDoDisposeCaller(); private int pendingTasks = 0; private readonly object lockObj = new object(); public DoSomething() { // Do whatever. } public AsyncDoSomething() { lock ( lockObj ) { pendingTasks++; AsyncDoSomethingCaller caller = new AsyncDoSomethingCaller(); caller.BeginInvoke( new AsyncCallback( EndDoSomethingCallback ), caller); } } public Dispose() { AsyncDoDisposeCaller caller = new AsyncDoDisposeCaller(); caller.BeginInvoke( new AsyncCallback( EndDoDisposeCallback ), caller); } private DoDispose() { WaitForPendingTasks(); // Finally, dispose whatever managed and unmanaged resources. } private void WaitForPendingTasks() { while ( true ) { // Check if there is a pending task. lock ( lockObj ) { if ( pendingTasks == 0 ) { return; } } // Allow other threads to execute. Thread.Sleep( 0 ); } } private void EndDoSomethingCallback( IAsyncResult ar ) { lock ( lockObj ) { AsyncDoSomethingCaller caller = (AsyncDoSomethingCaller) ar.AsyncState; caller.EndInvoke( ar ); pendingTasks--; } } private void EndDoDisposeCallback( IAsyncResult ar ) { AsyncDoDisposeCaller caller = (AsyncDoDisposeCaller) ar.AsyncState; caller.EndInvoke( ar ); } }I see a problem with this approach. As the release of resources is asynchronously done, something like this might work:
MyClass myClass; using ( myClass = new MyClass() ) { myClass.AsyncDoSomething(); } myClass.DoSomething();When the expected behavior should be to launch an ObjectDisposedException when DoSomething() is called outside the using clause. But I don't find this bad enough to rethink this solution.
Rob McCready : In the using (MyClass myclass = new....) example I think the myclass object becomes unanchored at the end of the using block and available to be Finalized. I'm pretty sure to be safe you need to call and block on a Waiting method before the end of the using block.
