windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
지난 글에 설명한 Monitor.Enter/Exit,
windbg - Monitor.Enter의 thin lock과 fat lock
; https://www.sysnet.pe.kr/2/0/13552
즉 lock 구문은 배타적 잠금을 위한 스레드 동기화 용도로 종종 사용하게 되는데요, 반면
Monitor.Wait/Pulse는 EventWaitHandle처럼 이벤트를 Signal하는 용도로 사용할 수 있습니다.
간단하게 예제 코드를 볼까요?
internal class Program
{
static object _lock = new object();
static void Main(string[] args)
{
ThreadPool.QueueUserWorkItem((obj) =>
{
lock (_lock)
{
Console.WriteLine("ThreadPool thread waiting...");
Monitor.Wait(_lock); // 누군가 Pulse/PulseAll을 하기까지 대기
Console.WriteLine("ThreadPool thread waited!");
}
});
Thread.Sleep(5000);
lock (_lock)
{
Console.WriteLine("Signal-pulse-enter");
Monitor.Pulse(_lock); // Wait을 하고 있는 스레드를 깨움
Console.WriteLine("Signal-pulse-exit");
}
Thread.Sleep(1000);
}
}
/* 출력 결과
ThreadPool thread waiting...
Signal-pulse-enter
Signal-pulse-exit
ThreadPool thread waited!
*/
위의 프로그램은 스레드풀의 스레드가 lock + Wait을 하며 신호를 대기하는데, 5초 후 Main 스레드에서 lock + Pulse를 함으로써 Wait 대기를 풀어 줍니다. (달리 말하면, 한 쪽은 Consumer, 한 쪽은 Producer처럼 동작하는 구조가 되는 것입니다.)
기존에 우리가 알고 있던 바에 따르면, 위의 코드에서 스레드풀의 스레드가 lock을 하고 있기 때문에 Main 스레드에서의 lock 진입이 불가능해야 합니다. 하지만, Monitor.Wait을 하는 순간 _lock의 배타적 소유권이 해제됨으로써, 즉 thin-lock이 해제되기 때문에 Main 스레드의 lock 진입이 가능하게 됩니다.
실제로 이것을 windbg를 이용해 확인해 볼까요? ^^ 우선, 예제를 다음과 같이 바꾸고,
internal class Program
{
static object _lock = new object();
static void Main(string[] args)
{
Console.WriteLine("Step1");
Debugger.Break();
lock (_lock)
{
Console.WriteLine("Step2");
Debugger.Break();
Monitor.Wait(_lock);
}
}
}
windbg로 위의 프로그램을 실행시켜 "Step1" 출력이 된 시점에 thin/fat lock을 조사하면 이렇게 나옵니다.
0:000> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 0
CCW 0
RCW 0
ComClassFactory 0
Free 0
아직 lock 구문에 진입하기 전이므로 당연한 결과입니다. 이후, "Step2" 출력 단계까지 실행하면, 즉, lock (_lock) 구문을 실행 중인 시점에 다시 thin/fat lock을 조사하면 이렇게 나옵니다.
0:000> !dumpheap -thinlock
Address MT Size
0306246c 72a4ae50 12 ThinLock owner 1 (012ab3f0) Recursive 0
Found 1 objects.
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 0
CCW 0
RCW 0
ComClassFactory 0
Free 0
thinlock이 _lock object 개체에 걸린 것을 볼 수 있는데요, 이후 Monitor.Wait 호출까지 실행시킨 단계로 진입하게 되면, 이제 thin/fat lock은 다음과 같이 바뀝니다.
0:008> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:008> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 1
CCW 0
RCW 0
ComClassFactory 0
Free 0
Wait의 호출로 _lock 개체에 걸려있던 thinlock이 풀렸는데요, 재미있는 건 syncblk의 결과에 "Total" 값은 1로 늘었지만 정작 SyncBlock 테이블에는 아무런 값이 없다는 점입니다. 왜냐하면, 실제로 "_lock" 개체가 잠김 처리된 것이 아니므로 그것을 소유한 스레드가 없어 소유자를 구분할 수 있는 기준 자체가 없는 상태이기 때문입니다.
예상할 수 있겠지만, 다중 스레드에서 Wait을 호출하면, 그 수만큼 !syncblk의 Total 수치가 늘어납니다. 이에 대한 테스트를 다음의 코드로 할 수 있습니다.
internal class Program
{
static object _lock = new object();
static void Main(string[] args)
{
for (int i = 0; i < 35; i++)
{
int n = i;
new Thread(() =>
{
lock (_lock)
{
Console.WriteLine($"{n} thread waiting...");
Monitor.Wait(_lock);
Console.WriteLine($"{n} thread waited!");
}
}).Start();
}
lock (_lock)
{
Console.WriteLine("Main thread waiting...");
Monitor.Wait(_lock);
Console.WriteLine("Main thread waited!");
}
}
}
Main 스레드의 Wait 호출까지 포함해 총 36개의 스레드가 Monitor.Wait에 빠져버리는데요, 이때의 syncblk을 확인하면 이렇게 나옵니다.
0:041> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:043> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 36
CCW 0
RCW 0
ComClassFactory 0
Free 0
재미있는 점이 있다면, 개별 생성한 스레드에 대해서만 syncblk의 Total 값이 Wait 호출 수를 반영할 뿐 스레드풀 내의 스레드에서 Wait을 호출하면 Total에 누적되지 않는다는 점입니다.
internal class Program
{
static object _lock = new object();
static void Main(string[] args)
{
ThreadPool.GetMinThreads(out _, out var cpt);
ThreadPool.SetMinThreads(35, cpt);
for (int i = 0; i < 35; i++)
{
int n = i;
ThreadPool.QueueUserWorkItem((obj) =>
{
lock (_lock)
{
Console.WriteLine($"{n} thread waiting...");
Monitor.Wait(_lock);
Console.WriteLine($"{n} thread waited!");
}
});
}
lock (_lock)
{
Console.WriteLine("Main thread waiting...");
Monitor.Wait(_lock);
Console.WriteLine("Main thread waited!");
}
}
}
이때의 상황을 조사해 보면,
0:042> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:042> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 2
CCW 0
RCW 0
ComClassFactory 0
Free 0
Main 스레드의 Wait 1번만 Total에 반영되었을 뿐 Total에 반영된 남은 1번은 ThreadPool.QueueUserWorkItem 호출로 인한 스레드풀 내부의 동작에 의해 추가된 것에 불과합니다.
참고로, ThreadPool.QueueUserWorkItem 영역을 Task.Run으로 바꾸면,
// 35개의 Task.Run 호출
Task.Run(() =>
{
lock (_lock)
{
Console.WriteLine($"{n} thread waiting...");
Monitor.Wait(_lock);
Console.WriteLine($"{n} thread waited!");
}
});
약간 다른 값이 나오긴 하는데요,
0:045> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:045> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 6
CCW 1
RCW 2
ComClassFactory 0
Free 0
이번에도 마찬가지로, Total에 추가된 5번, "CCW 1", "RCW 2"는 Task 라이브러리 초기화 중 관련된 lock으로 인한 결과입니다.
마지막으로, lock + Wait이 아닌 lock + Pulse를 하게 되면,
internal class Program
{
static object _lock = new object();
static void Main(string[] args)
{
lock (_lock)
{
Monitor.Pulse(_lock);
Debugger.Break();
}
}
}
lock (_lock) 코드로 인해 잠깐 thinlock이 생겼다가, Monitor.Pulse 호출 이후에는 syncblk이 생성되는 것을 볼 수 있습니다.
0:000> !dumpheap -thinlock
Address MT Size
Found 0 objects.
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
1 0123f02c 1 1 0121b458 2f2c 0 02fb246c System.Object
-----------------------------
Total 1
CCW 0
RCW 0
ComClassFactory 0
Free 0
이렇게 생긴 syncblk은 lock (...) 블록을 벗어나야 없어집니다. 결국, lock + Wait과는 달리 lock + Pulse는 다른 스레드의 lock 진입을 막으므로 가능한 한 빨리 블록을 빠져나오도록 해야 합니다.
정리해 보면, Monitor.Wait으로 인한 스레드 대기 현상은 메모리 덤프 파일로부터 관련 정보를 찾아내기가 매우 힘들다는 특징이 있습니다. 물론, Wait과 Pulse(All) 쌍은 대부분의 경우
Producer/Consumer 모델에서 사용하므로 딱히 Wait 대기 상태를 풀어줄 스레드를 굳이 찾아내야 할 필요는 거의 없습니다.
반면, Wait/Pulse(All)를 lock(obj) 형태처럼 동작해야 할 코드에 응용하는 것은 자칫 디버깅을 힘들게 할 수 있으므로 사용 시 주의를 기울이는 것이 좋습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]