Образец мертвой блокировки в .NET?

Есть еще один способ добиться взаимоблокировки в C #. Начиная с .NET 2.0 SP1 количество потоков в пуле ограничено 250 (с 25 в предыдущей версии) на ядро.

Таким образом, технически вы можете запустить слишком много задач в пуле, которые ждут завершения другой асинхронной операции (которая выполняется через пул потоков). Таким образом, задача в пуле не будет выпущена, и задача async не запустится из-за отсутствия доступных потоков.

Вы можете найти пример и более точное объяснение здесь: Программирование пула потоков. Тупики

Для примера кода с блокировкой, попробуйте использовать lock(this) в своем классе, чтобы смоделировать сценарий блокировки. Посмотрите этот пример.

Следующие две статьи, достойные прочтения, обнаруживают тупик во время выполнения и обсуждают способы его избежать.

1. Deadlock monitor Стивена Тоуба.
2. TimedLock Again от Ian Griffiths.

Один из распространенных способов - использовать вложенные блокировки, которые не устанавливаются в одном и том же порядке. Поток 1 может получить блокировку A, а поток 2 может получить блокировку B, и они войдут в тупик.

var a = new object();
var b = new object();

lock(a) {
   lock(b) {

   }
}

// other thread
lock (b) { 
  lock(a) {

  }
}

править: пример без блокировки .. с использованием дескрипторов ожидания. Предположим, что Сократ и Декарт едят стейки, и они оба, будучи хорошо воспитанными философами, нуждаются в вилке и ноже, чтобы есть. Однако у них есть только один набор столового серебра, поэтому каждый может взять одну посуду, а затем вечно ждать, пока другая отдаст свою посуду.

См. Проблема философского обеда

WaitHandle fork = new AutoResetEvent(), knife = new AutoResetEvent();

while(Socrates.IsHungry) {
   fork.WaitOne();
   knife.WaitOne();
   Eat();
   fork.Set();
   knife.Set();
} 

// other thread
while(Descartes.IsHungry) {
   knife.WaitOne();
   fork.WaitOne();
   Eat();
   knife.Set();
   fork.Set();
} 

Это типичный код для создания тупиковой ситуации в коде C #. Ознакомьтесь с этой статьей MSDN: http://msdn.microsoft.com/en-us/magazine/cc188793.aspx

using System;

using System.Threading;


public class Simple {

    static object A = new object();

    static object B = new object();


    static void MethodA()
    {
        Console.WriteLine("Inside methodA");
        lock (A)
        {
            Console.WriteLine("MethodA: Inside LockA and Trying to enter LockB");
            Thread.Sleep(5000);           
            lock (B)
            {
                Console.WriteLine("MethodA: inside LockA and inside LockB");
                Thread.Sleep(5000);
            }
            Console.WriteLine("MethodA: inside LockA and outside LockB");
        }
        Console.WriteLine("MethodA: outside LockA and outside LockB");
    }

    static void MethodB()
    {
        Console.WriteLine("Inside methodB");
        lock (B)
        {
            Console.WriteLine("methodB: Inside LockB");
            Thread.Sleep(5000);
            lock (A)
            {
                Console.WriteLine("methodB: inside LockB and inside LockA");
                Thread.Sleep(5000);
            }
            Console.WriteLine("methodB: inside LockB and outside LockA");
        }
        Console.WriteLine("methodB: outside LockB and outside LockA");
    }

    public static void Main(String[] args)
    {

        Thread Thread1 = new Thread(MethodA);
        Thread Thread2 = new Thread(MethodB);
        Thread1.Start();
        Thread2.Start();
        Console.WriteLine("enter.....");
        Console.ReadLine();

    }
}

Чтобы ответить на часть вашего вопроса об обнаружении тупиковых ситуаций, я сомневаюсь, что это вообще возможно. Это похоже на проблему остановки, вы не можете эффективно вычислить семантику. Один из способов преодолеть это - использовать сторожевой пёс, который будет периодически опрашивать каждый поток, жив ли он ещё, и давать ему определённое время на ответ, если 2 потока не отвечают, можно предположить, что они либо заняты, либо находятся в тупике.