In a yield return function is it possible to ensure that the finalizer is called on the same thread?

Question

I have a tricky problem that is turning up in some of my code. I have a cache manager that either returns items from the cache or calls a delegate to create them (expensively).

I'm finding that I'm having problems with the finalize part of my method being run on a different thread than the rest.

Here's a cut down version

public IEnumerable<Tuple<string, T>> CacheGetBatchT<T>(IEnumerable<string> ids, BatchFuncT<T> factory_fn) where T : class
    {

        Dictionary<string, LockPoolItem> missing = new Dictionary<string, LockPoolItem>();

        try
        {
            foreach (string id in ids.Distinct())
            {
                LockPoolItem lk = AcquireLock(id);
                T item;

                item = (T)resCache.GetData(id); // try and get from cache
                if (item != null)
                {
                    ReleaseLock(lk);
                    yield return new Tuple<string, T>(id, item);
                }
                else
                    missing.Add(id, lk);                    
            }

            foreach (Tuple<string, T> i in factory_fn(missing.Keys.ToList()))
            {
                resCache.Add(i.Item1, i.Item2);
                yield return i;
            }

            yield break;                        // why is this needed?
        }
        finally
        {
            foreach (string s in missing.Keys)
            {
                ReleaseLock(l);
            }
        }
    }

Acquire and Release lock fill a dictionary with LockPoolItem objects that have been locked with Monitor.Enter / Monitor.Exit [I have also tried mutexes]. The problem is coming when ReleaseLock is being called on a different thread from the one AcquireLock was called on.

The problem comes when calling this from another function that uses threads sometimes the finalize block gets called, due to the disposal of the IEnumerator running on the returned iterate.

The following block is a simple example.

BlockingCollection<Tuple<Guid, int>> c = new BlockingCollection<Tuple<Guid,int>>();

            using (IEnumerator<Tuple<Guid, int>> iter = global.NarrowItemResultRepository.Narrow_GetCount_Batch(userData.NarrowItems, dicId2Nar.Values).GetEnumerator()) {
                Task.Factory.StartNew(() => {

                    while (iter.MoveNext()) {
                        c.Add(iter.Current);
                    }
                    c.CompleteAdding();
                });
            }

This doesn't seem to happen when I add the yield break - however I'm finding this hard to debug as it only occurs very occasionally. However, it does happen - I've tried logging the thread ids and finalize if getting called on different threads...

I'm sure this can't be correct behaviour: I can't see why the dispose method (i.e. exit using) would get called on a different thread.

Any ideas how to guard against this?

Answer 1

There seems to be a race here.

It looks like your calling code creates the enumerator, then starts a task on the thread pool to enumerate through it, then disposes of the enumerator. My initial thoughts:

• If the enumerator is disposed before it enumeration starts, nothing will happen. From a brief test, this doesn't prevent enumeration after it's disposed.

• If the enumerator is disposed while enumerating, the finally block will be called (on the calling thread) and enumeration will stop.

• If enumeration is completed by the task action, the finally block will be called (on the thread pool thread).

To attempt to demonstrate, consider this method:

private static IEnumerable<int> Items()
{            
    try
    {
        Console.WriteLine("Before 0");

        yield return 0;

        Console.WriteLine("Before 1");

        yield return 1;

        Console.WriteLine("After 1");
    }
    finally 
    {
        Console.WriteLine("Finally");
    }
}

If you dispose before enumerating, nothing will be written to the console. This is what I suspect you will be doing most of the time, as the current thread reaches the end of the using block before the task begins:

var enumerator = Items().GetEnumerator();
enumerator.Dispose();    

If enumeration completes before Dispose, the final call to MoveNext will invoke the finally block.

var enumerator = Items().GetEnumerator();
enumerator.MoveNext();
enumerator.MoveNext();
enumerator.MoveNext();

Result:

"Before 0"
"Before 1"
"After 1"
"Finally"

If you dispose while enumerating, the call to Dispose will call the finally block:

var enumerator = Items().GetEnumerator();
enumerator.MoveNext();
enumerator.Dispose();

Result:

"Before 0"
"Finally"

I'd suggest you create, enumerate and dispose of the enumerator on the same thread.

Answer 2

Thanks to all the replies I realised what was going on and why. The solution to my problem was then quite easy. I just had to ensure everything was called on the same thread.

        BlockingCollection<Tuple<Guid, int>> c = new BlockingCollection<Tuple<Guid,int>>();

        Task.Factory.StartNew(() => {
            using (IEnumerator<Tuple<Guid, int>> iter = global.NarrowItemResultRepository.Narrow_GetCount_Batch(userData.NarrowItems, dicId2Nar.Values).GetEnumerator()) {

                while (iter.MoveNext()) {
                    c.Add(iter.Current);
                }
                c.CompleteAdding();
            }
        });

Answer 3

The term "finalizer" relates to a concept totally unrelated to a "'finally' block"; nothing about the threading context of finalizers is guaranteed, but I think you're actually interested in "finally" blocks.

A finally block surrounded by a yield return will be executed by whatever thread calls Dispose on the iterator's enumerator. Enumerators are generally entitled to assume that all operations performed on them, including Dispose, will be done by the same thread that created them, and are generally under no obligation to behave in anything even remotely resembling a sensible fashion in cases where they are not. The system does not prevent code from using enumerators on multiple threads, but in the event that a program uses from multiple threads an enumerator which makes no promise that it will work in that regard means that any consequences resulting therefrom are not the fault of the enumerator, but rather the fault of the program that used it illegitimately.

Generally, it is good for classes to include enough protection against invalid multi-threading to ensure that improper multi-threaded use will not cause security vulnerabilities, but not worry about preventing any other sort of harm or confusion.