Microsoft MVP성태의 닷넷 이야기
닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse [링크 복사], [링크+제목 복사],
조회: 5028
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 3개 있습니다.)
디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
; https://www.sysnet.pe.kr/2/0/11268

닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
; https://www.sysnet.pe.kr/2/0/13552

닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
; https://www.sysnet.pe.kr/2/0/13553




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) 형태처럼 동작해야 할 코드에 응용하는 것은 자칫 디버깅을 힘들게 할 수 있으므로 사용 시 주의를 기울이는 것이 좋습니다.





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/14/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13609정성태4/27/20244836닷넷: 2250. PInvoke 호출 시 참조 타입(class)을 마샬링하는 [IN], [OUT] 특성파일 다운로드1
13608정성태4/26/20245015닷넷: 2249. C# - 부모의 필드/프로퍼티에 대해 서로 다른 자식 클래스 간에 Reflection 접근이 동작할까요?파일 다운로드1
13607정성태4/25/20244668닷넷: 2248. C# - 인터페이스 타입의 다중 포인터를 인자로 갖는 C/C++ 함수 연동
13606정성태4/24/20244692닷넷: 2247. C# - tensorflow 연동 (MNIST 예제)파일 다운로드1
13605정성태4/23/20245153닷넷: 2246. C# - Python.NET을 이용한 파이썬 소스코드 연동파일 다운로드1
13604정성태4/22/20244424오류 유형: 901. Visual Studio - Unable to set the next statement. Set next statement cannot be used in '[Exception]' call stack frames.
13603정성태4/21/20244838닷넷: 2245. C# - IronPython을 이용한 파이썬 소스코드 연동파일 다운로드1
13602정성태4/20/20244722닷넷: 2244. C# - PCM 오디오 데이터를 연속(Streaming) 재생 (Windows Multimedia)파일 다운로드1
13601정성태4/19/20244756닷넷: 2243. C# - PCM 사운드 재생(NAudio)파일 다운로드1
13600정성태4/18/20244932닷넷: 2242. C# - 관리 스레드와 비관리 스레드
13599정성태4/17/20244884닷넷: 2241. C# - WAV 파일의 PCM 사운드 재생(Windows Multimedia)파일 다운로드1
13598정성태4/16/20245874닷넷: 2240. C# - WAV 파일 포맷 + LIST 헤더파일 다운로드2
13597정성태4/15/20244900닷넷: 2239. C# - WAV 파일의 PCM 데이터 생성 및 출력파일 다운로드1
13596정성태4/14/20245344닷넷: 2238. C# - WAV 기본 파일 포맷파일 다운로드1
13595정성태4/13/20245510닷넷: 2237. C# - Audio 장치 열기 (Windows Multimedia, NAudio)파일 다운로드1
13594정성태4/12/20245135닷넷: 2236. C# - Audio 장치 열람 (Windows Multimedia, NAudio)파일 다운로드1
13593정성태4/8/20245154닷넷: 2235. MSBuild - AccelerateBuildsInVisualStudio 옵션
13592정성태4/2/20246343C/C++: 165. CLion으로 만든 Rust Win32 DLL을 C#과 연동 [1]
13591정성태4/2/20245082닷넷: 2234. C# - WPF 응용 프로그램에 Blazor App 통합파일 다운로드1
13590정성태3/31/20244770Linux: 70. Python - uwsgi 응용 프로그램이 k8s 환경에서 OOM 발생하는 문제
13589정성태3/29/20245363닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20246036닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신 [2]파일 다운로드1
13587정성태3/27/20245280오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20247294Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20245724Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20245987개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법 [4]파일 다운로드1
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...