What is the correct way of adding thread-safety to an IDisposable object?

I tend to use an integer rather than a boolean as your field for storing the disposed status, because then you can use the thread-safe Interlocked class to test if Dispose has already been called.

Something like this:

private int _disposeCount;

public void Dispose()
{
    if (Interlocked.Increment(ref _disposeCount) == 1)
    {
        // disposal code here
    }
}

This ensures that the disposal code is called only once not matter how many times the method is called, and is totally thread safe.

Then each method can quite simply use call this method as a barrier check:

private void ThrowIfDisposed()
{
   if (_disposeCount > 0) throw new ObjectDisposedException(GetType().Name);
}

With regard to synchronising every method - are you saying a simple barrier check won't do - that you want to stop other threads that might be already executing code in the instance. This is a more complex problem. I don't know what your code is doing, but consider if you really need that - will a simple barrier check not do?

If you just meant with regard to the disposed check itself - my example above is fine.

EDIT: to answer the comment "What's the difference between this and a volatile bool flag? It's slightly confusing to have a field named somethingCount and allow it to hold 0 and 1 values only"

Volatile is related to ensuring the read or write operation operation is atomic and safe. It doesn't make the process of assigning and checking a value thread safe. So, for instance, the following is not thread safe despite the volatile:

private volatile bool _disposed;

public void Dispose()
{
    if (!_disposed)
    {
        _disposed = true

        // disposal code here
    }
}

The problem here is that if two threads were close together, the first could check _disposed, read false, enter the code block and get switched out before setting _disposed to true. The second then checks _disposed, sees false and also enters the code block.

Using Interlocked ensures both the assignment and subsequent read are a single atomic operation.

Most BCL implementations of Dispose are not thread-safe. The idea is that it's up to the caller of Dispose to make sure nobody else is using the instance anymore before it is Disposed. In other words, it pushes the synchronization responsibility upwards. This makes sense, as otherwise now all your other consumers need to handle the boundary case where the object was Disposed while they were using it.

That said, if you want a thread-safe Disposable class, you can just create a lock around every public method (including Dispose) with a check for _disposed at the top. This may become more complicated if you have long-running methods where you don't want to hold the lock for the entire method.

The simplest thing you can do is mark the private disposed variable as volatile and inspect it at the beginning of your methods. You can then throw an ObjectDisposedException if the object has already been disposed.

There are two caveats to this:

1. You shouldn't throw an ObjectDisposedExceptionif the method is an event handler. Instead you should just gracefully exit from the method if that is possible. The reason being is that there exists a race condition where events can be raised after you unsubscribe from them. (See this article by Eric Lippert for more information.)

2. This doesn't stop your class from being disposed while you are in the middle of executing one of your class methods. So if your class has instance members that can't be accessed after disposal, you're going to need to setup some locking behaviour to ensure access to these resources are controlled.

Microsoft's guidance around IDisposable says you should check for disposed on all methods, but I haven't personally found this necessary. The question really is, is something going to throw an exception or cause unintended side effects if you allow a method to execute after the class is disposed. If the answer is yes, you need to do some work to make sure that doesn't happen.

In terms of whether all IDisposable classes should be thread safe: No. Most of the use cases for disposable classes involve them only ever being accessed by a single thread.

That being said, you may want to investigate why you need your disposable class to be thread safe as it adds a lot of additional complexity. There may be an alternate implementation that allows you to not have to worry about thread safety issues in your disposable class.