c# - IDisposable, ObjectDisposedException, and threadsafe types

Question

Is there any point in keeping track of the classic bool disposed field on an otherwise threadsafe type for the purposes of conditionally throwing an ObjectDisposedException at the beginning of all primary exposed methods?

I've seen this pattern recommended in a few places online but I'm not sure if the authors are using it correctly, so this question assumes that they are.

In such a scenario, it seems that the only way to ensure that the disposed condition is true beyond the condition's evaluation is to use a synchronization mechanism such as lock() over the entire body of each exposed member including the Dispose(bool) method. Wouldn't this make the type effectively single-threaded again?

And if this is true, then there'd be no point in using it, and therefore you can't rely on the ObjectDisposedException mechanism in some IDisposable implementations - so then why would we EVER employ this mechanism if it isn't necessary?

====

I guess IDisposable and ObjectDisposedException just don't go together for thread-safe types.

Answer 1

Perhaps a more efficient way of making a threadsafe object not become disposed while a method is running is to use a ReaderWriterLockSlim. Have all the public methods obtain a read lock while executing and release it when they're done. Have Dispose obtain a writer lock. It will wait till all the other methods are done before it obtains it's write lock. It then sets isDisposed inside the write lock which it exclusively holds. Any calls to public methods after Dispose is done can see isDisposed and throw the ObjectDisposedException.

ReaderWriterLockSlim

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

Answer 2

オブジェクトがすでに破棄されている場合にオブジェクトの動作が異なり、破棄後に使用される可能性が高い場合は、これを追跡する必要があります。ObjectDisposedExceptionオブジェクトがすでに破棄されていて、最初にチェックしない場合に発生するランダムな例外をスローするよりも、スローする方が適切です。

Answer 3

Given that the "Disposed" boolean is only updated in one place, and it is a bug in your caller to use the object after they had called Disposed.

I think it is good enough to throw ObjectDisposedException "most of the time" after Dispose has been called. I see ObjectDisposedException as being a debug helper not thingthing that a caller should be catching.

Answer 4

If there is a possibility of a method being called while an object is disposed, the method's semantics should be defined in such a way that calling it on a disposed object will pose no problem. In cases where there may or may not be a problem, one should use the "try/do" pattern. If Microsoft had followed this principle with Control.BeginInvoke, there would be both a "Control.BeginInvoke" and a "Control.TryBeginInvoke"; the latter would be explicitly defined as returning false and doing nothing if a control was disposed prior to the action being enqueued (note that Control.BeginInvoke returning true would not guarantee that the control wouldn't get disposed before the action was actually run). This pattern would be very useful in things like display-update scenarios: if a control isn't disposed, I want its update routine to run; if it gets disposed before the update routine runs, however, the update will become moot and its failure to run would hardly be a problem.