Dispose pattern in multithreaded application

[Bruce]

Hi
I have a question on handling Dispose() in an application I wrote.
When I get a signal to stop the application, I have a central class
that disposes all the other classes to release native resources.
Since there are callback methods in the classes, If I have a class A
that has IDisposable implemented, when Dispose is called, any of the
other methods in A could be executing and end up throwing weird
exceptions
How to handle these scenarios gracefully? I thought of 2 options

1. Have a inDisposing flag on the class that is set when Dispose()
gets called. In every method, catch all exceptions, rethrow them if
inDisposing is false. Swallow them otherwise.
2. In every method, lock a disposeLock object, check if disposed flag
is true, if not do the work and release it at the end. Dispose() also
tries to get hold of the lock before disposing.

I am not sure what is the recommended way of handling exceptions that
occur in different threads because of calling Dispose.

Thanks
Bruce

 

[Bruce]

It depends.  I would say that generally, some kind of synchronization is  
required.  What that would be depends on how the objects are designed and  
used.  You can have a special "dispose-only" lock, but in truth most of 
the time you really just need to synchronize all access to the object.  
Normally that synchronization would address the dispose issue as well, and  
often may not even be part of the implementation of the disposable class  
itself.

If doing the synchronization in the class that declares the event, one  
issue that comes up is the question of whether to hold the lock while  
raising the event (i.e. calling the subscribers).  Releasing the lock  
before raising the event complicates the code in one way, but it avoids  
issues related to the event callbacks taking too long to execute thus  
causing the lock to be held longer, and reduces the chances of deadlock.

Of course another question is whether the classes you are concerned with  
being disposed during the callback is the class implementing the callback 
or the one calling it.  The solutions are similar in either case, but  
there are obviously subtle differences (e.g. the question of hold/release 
lock before calling a callback goes away if the lock is in the callee, not  
the caller ).

It's impossible to know exactly what would be best for you, without an  
actual concise-but-complete code example that effectively demonstrates how  
your code is arranged and what you're doing with it.

Pete

Thanks for the reply Pete. It is a little difficult to get out a
representative code sample, but I guess I have to synchronize inside
Dispose and any method that uses the resources disposed by Dispose and
throw ObjectDisposeException in those methods if disposed has
happened.
It is a painful pattern to work with in the sense that more work is
needed to cleanup resources than to do the actual work! A flag to
indicate disposed or not, a lock to do synchronization and various
checks all over the code to make sure we are not doing work after the
object is disposed, cancel callbacks etc.
Maybe it is easier to just shut down the application and restart...