使用Parallel.ForEach中的Convert.ChangeType进行死锁

Question

I just had to debug a code with a deadlock, but I can't really find the reason why. In detail the deadlock happens when calling Convert.ChangeType within a Parallel.ForEach loop.

I try to find any Information about the thread-safety of this method, but I wasn't able to find some. So I had a look at the .NET source code and tried to do what they do, so I don't need to call Convert.ChangeType . And finally the code run without the deadlock.

In my example code I convert an enumeration type to its underlaying ulong type:

public class TestClass<T> where T : struct, IConvertible
{
    private static readonly Type uLongType = typeof(ulong);
    public static readonly TestClass<T> Instance = new TestClass<T>();

    private readonly Dictionary<string, object> _NumericValues = new Dictionary<string, object>();
    private readonly Dictionary<string, T> _Values = new Dictionary<string, T>();

    public TestClass()
    {
        if (!typeof(T).IsEnum) throw new InvalidOperationException("Enumeration type required");
        Type t = typeof(T);
        foreach (T value in Enum.GetValues(t)) _Values[Enum.GetName(t, value)] = value;
        // Deadlock at Convert.ChangeType
        Parallel.ForEach(ValueNames, new Action<string>((key) =>
        {
            object value = Convert.ChangeType(_Values[key], uLongType);
            lock (_NumericValues) _NumericValues[key] = value;
            // In real life here comes a lot more code...
        }));
        // Works!
        Parallel.ForEach(ValueNames, new Action<string>((key) =>
        {
            object value = ((IConvertible)_Values[key]).ToUInt64(null);
            lock (_NumericValues) _NumericValues[key] = value;
        }));
    }

    public string[] ValueNames => new List<string>(_Values.Keys).ToArray();
}

public enum TestEnum : ulong
{
    Value1,
    Value2,
    Value3
}

To reproduce fe:

System.Diagnostics.Debug.WriteLine(TestClass<TestEnum>.Instance.ValueNames.Length);

But I don't really understand, why Convert.ChangeType is causing a deadlock - does anyone have any idea?

Edit : It works with Convert.ChangeType , if I initialize Instance within a static constructor - but why the heck?

    public static readonly TestClass<T> Instance = null;

    static TestClass()
    {
        Instance = new TestClass<T>();
    }

Answer 1

The cause is nothing to do with Convert.ChangeType , it just happens to exhibit the issue because the call references the static uLongType field, which causes the TestClass<T> type initializer to run.

The real culprit is the static Instance field that creates a new TestClass<T> instance. This creates a potential deadlock as the type initializer requires the instance constructor to complete, but the instance constructor is waiting on multiple threads which in turn wait for the type initializer to complete.

Adding a static constructor, which removes the beforefieldinit type attribute and changes type initialization behavior as mentioned in the comments, only semi-reliably hides the deadlock in combination with an attached debugger in my tests. It doesn't really solve the issue.

Here is a simplified example which exhibits the problem most of the time:

static void Main()
{
    new TestClass();
    Console.WriteLine("Not deadlocked");
}

public class TestClass
{
    static Type uLongType = typeof(ulong);
    static TestClass Instance = new TestClass();

    static TestClass() { }

    public TestClass()
    {
        var values = Enumerable.Range(0, 20).ToList();

        Parallel.ForEach(values, (value) =>
        {
            uLongType.ToString();

            //Forcing the lambda to be compiled as an instance method
            //changes the behavior but deadlocks can happen either way
            InstanceMethod();
        });
    }

    void InstanceMethod() { }
}

The deadlocking probability varies depending on the combination of instance and/or static usage in the lambda, attached debugger, release optimizations, static constructor, Console.WriteLine call in the lambda, and random Parallel thread scheduling, but it can always happen.

Answer 2

I think the problem is purely that you are performing a blocking operating inside a type initializer. The CLR has to run type initializers inside a lock, as it has to prevent them from ever being run twice, and it uses the same lock for all types. If you do threading inside your type initializer, and you block, then you risk deadlock.

I think that's exactly what's happening here:

1. The main thread grabs the type initializer lock and runs the type initializer
2. Another thread is spawned, which accesses the Convert class, which needs to run its type initializer. So it tries to grab the type initializer lock
3. The main thread blocks waiting for the second thread to complete, holding the type initializer lock
4. Deadlock

You didn't see this when calling IConvertable.ToUInt64 directly, because that didn't need to call the Convert class's type initializer.

When your TestClass<T>.Instance is assigned inline, the BeforeFieldInit flag gets set. This means the CLR uses a relaxed approach to running the type initializer, and in my testing it ran it before Main , before the type initializer for Convert had been run. When you defined an explicit static constructor, the CLR was forced to run the type initializer when TestClass<T>.Instance was first referenced in Main , presumably after Convert had been initialized, which happened to avoid the deadlock.

My evidence for this is knowledge of how type initializers are run, the fact that the thread blocks somewhere inside the runtime (but before it gets a chance to run the method Convert.ChangeType ), and the fact that merely referencing the Convert type is enough to trigger this.

See this MSDN article . I think the takeaway is that you probably shouldn't be doing threading in your type initializer, and you definitely shouldn't be blocking the thread which is running the type initializer.

I'd be happy to take at your actual (non-simplified) problem, and try a suggest ways of improving its performance without resorting to threading in the type initializer.