static object object1 = new object();
static object object2 = new object();
public static void ObliviousFunction()
{
lock (object1)
{
Thread.Sleep(1000); // Wait for the blind to lead
lock (object2)
{
}
}
}
public static void BlindFunction()
{
lock (object2)
{
Thread.Sleep(1000); // Wait for oblivion
lock (object1)
{
}
}
}
static void Main()
{
Thread thread1 = new Thread((ThreadStart)ObliviousFunction);
Thread thread2 = new Thread((ThreadStart)BlindFunction);
thread1.Start();
thread2.Start();
while (true)
{
// Stare at the two threads in deadlock.
}
}
На другом конце шкалы отдельные контексты синхронизации вызывают взаимоблокировки. Вот пример:
[Synchronization]
public class Deadlock : ContextBoundObject {
public DeadLock Other;
public void Demo() { Thread.Sleep (1000); Other.Hello(); }
void Hello() { Console.WriteLine ("hello"); }
}
public class Test {
static void Main() {
Deadlock dead1 = new Deadlock();
Deadlock dead2 = new Deadlock();
dead1.Other = dead2;
dead2.Other = dead1;
new Thread (dead1.Demo).Start();
dead2.Demo();
}
Поскольку каждый экземпляр Deadlock создается в рамках Test - несинхронизированного класса - каждый экземпляр получит свой собственный контекст синхронизации , а значит, и собственный замок. Когда два объекта обращаются друг к другу, тупик не занимает много времени (одна секунда, если быть точным!) проблема была бы особенно коварной, если бы классы Deadlock и Test были написаны разными командами программистов. Может быть неразумно ожидать, что ответственные за класс Test будут даже знать о своем нарушении, пусть в одиночку знает, как решить {{ 1}} это. Это отличается от явных блокировок, где взаимоблокировки обычно более очевидны.