Is this collection actually thread safe? Is concurrent Iterating, querying and modifying safe?

This is based on Alexey Drobyshevsky's excellent article Problems with Iteration

At Alexey's suggestion, I implemented his solution using a ReaderWriterLockSlim. Then I fleshed out a ThreadSafeList : IList implementation.

The idea here is to have a collection that multiple threads can iterate over, execute linq queries against, and modify at the same time without data inconsistencies, InvalidOperationExceptions, or deadlocks.

using System.Collections;
using System.Collections.Generic;
{

public class SafeEnumerator<T> : IEnumerator<T>
{

{
_innerCollection = innerCollection;
}

public void Dispose()
{
}

public bool MoveNext()
{
return _innerCollection.MoveNext();
}

public void Reset()
{
_innerCollection.Reset();
}

public T Current
{
get { return _innerCollection.Current; }
}

object IEnumerator.Current
{
get { return Current; }
}
}

{
private readonly List<T> _innerList = new List<T>();

IEnumerator<T> IEnumerable<T>.GetEnumerator()
{
try
{
}
finally
{
}
}

public IEnumerator GetEnumerator()
{
return (this as IEnumerable<T>).GetEnumerator();
}

{
try
{
}
finally
{
}
}

public void Clear()
{
try
{
_innerList.Clear();
}
finally
{
}
}

public bool Contains(T item)
{
try
{
return _innerList.Contains(item);
}
finally
{
}

}

public void CopyTo(T[] array, int arrayIndex)
{
try
{
_innerList.CopyTo(array, arrayIndex);
}
finally
{
}
}

public bool Remove(T item)
{
try
{
return _innerList.Remove(item);
}
finally
{
}
}

public int Count
{
get
{
try
{
return _innerList.Count;
}
finally
{
}
}
}

{
get
{
try
{
}
finally
{
}
}
}

public int IndexOf(T item)
{
try
{
return _innerList.IndexOf(item);
}
finally
{
}
}

public void Insert(int index, T item)
{
try
{
_innerList.Insert(index, item);
}
finally
{
}
}

public void RemoveAt(int index)
{
try
{
_innerList.RemoveAt(index);
}
finally
{
}
}

public T this[int index]
{
get
{
try
{
return _innerList[index];
}
finally
{
}
}

set
{
try
{
_innerList[index] = value;
}
finally
{
}
}
}
}

}

-
I believe this implementation may be prone to deadlocks. I have a unit test that starts 300 CRUD threads against a collection of 1,000,000 objects in a random fashion. 90% of the time the test returns within 10 seconds (8 core cpu) with all assertions passing. However, about 1 in 10 runs hangs indefinitely and throws no errors. My attempts to try to observe or log the deadlock come up empty. It never hangs in debug mode, and any writing to disk appears to change the timing just enough for the deadlock case to never occur. Your experience in solving deadlocks would be appreciated. –  Tion Jan 3 '12 at 14:51
I think that having concurrent threads reading & writing the collection without inconsistencies or deadlocks cannot be achieved. There has to be a compromise somewhere; regarding either data integrity or locking policy. Anyway, I find your question and Alexey's article very interesting. –  w0lf Jan 4 '12 at 10:26
I'm certainly finding out that it's very hard and may not be worth the effort. However, I'm still under the impression that it's theoretically possible to safely implement a collection that can be read and written to by multiple threads. I believe I should be able to avoid deadlocks while locking only on one resource. I think at this point I need a tool that will help me do a StackTrace dump of all the running threads. This is proving to be an extremely challenging exercise in Windows 7 with x64 .Net 4. –  Tion Jan 4 '12 at 18:16
I finally managed to create .dmp files that i can actually debug. (had to use procdump.exe because of 32 bit process on an x64 issues) I discovered some very odd behavior that occurs only when running in ReSharper test runner, and only when in run mode (not in debug mode). Very strangely the threads seem to hang at _readerWriterLock.ExitWriteLock(); why would RELEASING a lock be blocked!? What is it waiting for!? When running in as a console app, or even in R# test runner in debug mode, this bizarre blocking does not occur and it works perfectly as designed. R# must be doing something weird. –  Tion Jan 6 '12 at 20:34
I think that your CopyTo method only requires a read lock, not a write lock. –  Dr. Wily's Apprentice Jan 12 '12 at 20:32

Debugging multi threaded apps, for me, has always had the affect of aligning the threads and hiding deadlocks. This experience is mostly in native code, however i could imagine same thing could happen in managed. Not sure exactly why, but I think it has to do with introducing a delay on context switching in the debugger introspecting the stack and running it with symbols loaded. Depending on what the test is doing(Console.Write) running in console may have a similar affect aligning the thread while waiting for io.

Just my 2 cents i guess...

-
I wonder if Visual Studio's Intellitrace feature (Ultimate edition only, for now) would make it easier to debug multi-threading issues. If I understand it, one can use the dump file to effectively step through an already completed execution. –  Dr. Wily's Apprentice Jan 12 '12 at 20:42

I see that you're using the ReaderWriterLockSlim constructor with the SupportsRecursion LockRecursionPolicy.

Notice this line in the documentation for ReaderWriterLockSlim: "Regardless of recursion policy, a thread that initially entered read mode is not allowed to upgrade to upgradeable mode or write mode, because that pattern creates a strong probability of deadlocks."

However, I don't see anything in your code that makes me think that this is causing you a problem. In fact, calls to the EnterWriteLock method will throw a SynchronizationLockException if you have previously called EnterReadLock, so I'm sure you would have noticed that happening.

I see that there are multiple places in your code where you are doing this:

    try
{
// ...
}
finally
{
}


You should keep the call to EnterWriteLock outside of the try block, because if it fails for some reason, you don't want to call ExitWriteLock. The same goes for calls to EnterReadLock. It should be like this:

    _readerWriterLock.EnterWriteLock();
try
{
// ...
}
finally
{