성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] 제가 큰 실수를 했군요. ^^; Delegate를 통한 Bein...
[정성태] Working with Rust Libraries from C#...
[정성태] Detecting blocking calls using asyn...
[정성태] 아쉽게도, 커뮤니티는 아니고 개인 블로그입니다. ^^
[정성태] 질문이 잘 이해가 안 됩니다. 우선, 해당 소스코드에서 ILis...
[양승조
] var대신 dinamic으로 선언해서 해결은 했습니다. 맞는 해...
[양승조
] 또 막혔습니다. ㅠㅠ var list = props[i].Ge...
[양승조
] 아. 감사합니다. 어제는 안됐던것 같은데....정신을 차려야겠네...
[정성태] "props[i].GetValue(props[i])" 코드에서 ...
[정성태] 저렇게 조각 코드 말고, 실제로 재현이 되는 예제 프로젝트를 압...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<div style='display: inline'> <h1 style='font-family: Malgun Gothic, Consolas; font-size: 20pt; color: #006699; text-align: center; font-weight: bold'>windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse</h1> <p> 지난 글에 설명한 Monitor.Enter/Exit, <br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > windbg - Monitor.Enter의 thin lock과 fat lock ; <a target='tab' href='https://www.sysnet.pe.kr/2/0/13552'>https://www.sysnet.pe.kr/2/0/13552</a> </pre> <br /> 즉 lock 구문은 배타적 잠금을 위한 스레드 동기화 용도로 종종 사용하게 되는데요, 반면 <a target='tab' href='https://www.sysnet.pe.kr/2/0/1015#3'>Monitor.Wait/Pulse는 EventWaitHandle처럼 이벤트를 Signal하는 용도로 사용</a>할 수 있습니다.<br /> <br /> 간단하게 예제 코드를 볼까요?<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > internal class Program { static object _lock = new object(); static void Main(string[] args) { ThreadPool.QueueUserWorkItem((obj) => { <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine("ThreadPool thread waiting..."); <span style='color: blue; font-weight: bold'>Monitor.Wait(_lock);</span> // 누군가 Pulse/PulseAll을 하기까지 대기 Console.WriteLine("ThreadPool thread waited!"); } }); Thread.Sleep(5000); <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine("Signal-pulse-enter"); <span style='color: blue; font-weight: bold'>Monitor.Pulse(_lock);</span> // Wait을 하고 있는 스레드를 깨움 Console.WriteLine("Signal-pulse-exit"); } Thread.Sleep(1000); } } /* 출력 결과 ThreadPool thread waiting... Signal-pulse-enter Signal-pulse-exit ThreadPool thread waited! */ </pre> <br /> 위의 프로그램은 스레드풀의 스레드가 lock + Wait을 하며 신호를 대기하는데, 5초 후 Main 스레드에서 lock + Pulse를 함으로써 Wait 대기를 풀어 줍니다. (달리 말하면, 한 쪽은 Consumer, 한 쪽은 Producer처럼 동작하는 구조가 되는 것입니다.)<br /> <br /> 기존에 우리가 알고 있던 바에 따르면, 위의 코드에서 스레드풀의 스레드가 lock을 하고 있기 때문에 Main 스레드에서의 lock 진입이 불가능해야 합니다. 하지만, Monitor.Wait을 하는 순간 _lock의 배타적 소유권이 해제됨으로써, 즉 thin-lock이 해제되기 때문에 Main 스레드의 lock 진입이 가능하게 됩니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 실제로 이것을 windbg를 이용해 확인해 볼까요? ^^ 우선, 예제를 다음과 같이 바꾸고,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > internal class Program { static object _lock = new object(); static void Main(string[] args) { Console.WriteLine("Step1"); <span style='color: blue; font-weight: bold'>Debugger.Break(); lock (_lock)</span> { Console.WriteLine("Step2"); <span style='color: blue; font-weight: bold'>Debugger.Break(); Monitor.Wait(_lock);</span> } } } </pre> <br /> windbg로 위의 프로그램을 실행시켜 "Step1" 출력이 된 시점에 thin/fat lock을 조사하면 이렇게 나옵니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:000> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:000> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- Total 0 CCW 0 RCW 0 ComClassFactory 0 Free 0 </pre> <br /> 아직 lock 구문에 진입하기 전이므로 당연한 결과입니다. 이후, "Step2" 출력 단계까지 실행하면, 즉, lock (_lock) 구문을 실행 중인 시점에 다시 thin/fat lock을 조사하면 이렇게 나옵니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:000> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size 0306246c 72a4ae50 12 ThinLock owner 1 (012ab3f0) Recursive 0 Found 1 objects. 0:000> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- Total 0 CCW 0 RCW 0 ComClassFactory 0 Free 0 </pre> <br /> thinlock이 _lock object 개체에 걸린 것을 볼 수 있는데요, 이후 Monitor.Wait 호출까지 실행시킨 단계로 진입하게 되면, 이제 thin/fat lock은 다음과 같이 바뀝니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:008> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:008> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- <span style='color: blue; font-weight: bold'>Total 1</span> CCW 0 RCW 0 ComClassFactory 0 Free 0 </pre> <br /> Wait의 호출로 _lock 개체에 걸려있던 thinlock이 풀렸는데요, 재미있는 건 syncblk의 결과에 "Total" 값은 1로 늘었지만 정작 SyncBlock 테이블에는 아무런 값이 없다는 점입니다. 왜냐하면, 실제로 "_lock" 개체가 잠김 처리된 것이 아니므로 그것을 소유한 스레드가 없어 소유자를 구분할 수 있는 기준 자체가 없는 상태이기 때문입니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 예상할 수 있겠지만, 다중 스레드에서 Wait을 호출하면, 그 수만큼 !syncblk의 Total 수치가 늘어납니다. 이에 대한 테스트를 다음의 코드로 할 수 있습니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > internal class Program { static object _lock = new object(); static void Main(string[] args) { <span style='color: blue; font-weight: bold'>for (int i = 0; i < 35; i++)</span> { int n = i; <span style='color: blue; font-weight: bold'>new Thread(() =></span> { <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine($"{n} thread waiting..."); <span style='color: blue; font-weight: bold'>Monitor.Wait(_lock);</span> Console.WriteLine($"{n} thread waited!"); } }).Start(); } <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine("Main thread waiting..."); <span style='color: blue; font-weight: bold'>Monitor.Wait(_lock);</span> Console.WriteLine("Main thread waited!"); } } } </pre> <br /> Main 스레드의 Wait 호출까지 포함해 총 36개의 스레드가 Monitor.Wait에 빠져버리는데요, 이때의 syncblk을 확인하면 이렇게 나옵니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:041> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:043> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- <span style='color: blue; font-weight: bold'>Total 36</span> CCW 0 RCW 0 ComClassFactory 0 Free 0 </pre> <br /> <hr style='width: 50%' /><br /> <br /> 재미있는 점이 있다면, 개별 생성한 스레드에 대해서만 syncblk의 Total 값이 Wait 호출 수를 반영할 뿐 스레드풀 내의 스레드에서 Wait을 호출하면 Total에 누적되지 않는다는 점입니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > internal class Program { static object _lock = new object(); static void Main(string[] args) { ThreadPool.GetMinThreads(out _, out var cpt); ThreadPool.SetMinThreads(35, cpt); <span style='color: blue; font-weight: bold'>for (int i = 0; i < 35; i++)</span> { int n = i; <span style='color: blue; font-weight: bold'>ThreadPool.QueueUserWorkItem((obj) =></span> { <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine($"{n} thread waiting..."); <span style='color: blue; font-weight: bold'>Monitor.Wait(_lock);</span> Console.WriteLine($"{n} thread waited!"); } }); } <span style='color: blue; font-weight: bold'>lock (_lock)</span> { Console.WriteLine("Main thread waiting..."); <span style='color: blue; font-weight: bold'>Monitor.Wait(_lock);</span> Console.WriteLine("Main thread waited!"); } } } </pre> <br /> 이때의 상황을 조사해 보면,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:042> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:042> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- <span style='color: blue; font-weight: bold'>Total 2</span> CCW 0 RCW 0 ComClassFactory 0 Free 0 </pre> <br /> Main 스레드의 Wait 1번만 Total에 반영되었을 뿐 Total에 반영된 남은 1번은 ThreadPool.QueueUserWorkItem 호출로 인한 스레드풀 내부의 동작에 의해 추가된 것에 불과합니다.<br /> <br /> 참고로, ThreadPool.QueueUserWorkItem 영역을 Task.Run으로 바꾸면,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > // 35개의 Task.Run 호출 Task.Run(() => { lock (_lock) { Console.WriteLine($"{n} thread waiting..."); Monitor.Wait(_lock); Console.WriteLine($"{n} thread waited!"); } }); </pre> <br /> 약간 다른 값이 나오긴 하는데요,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:045> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:045> <span style='color: blue; font-weight: bold'>!syncblk</span> Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner ----------------------------- <span style='color: blue; font-weight: bold'>Total 6 CCW 1 RCW 2</span> ComClassFactory 0 Free 0 </pre> <br /> 이번에도 마찬가지로, Total에 추가된 5번, "CCW 1", "RCW 2"는 Task 라이브러리 초기화 중 관련된 lock으로 인한 결과입니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 마지막으로, lock + Wait이 아닌 lock + Pulse를 하게 되면,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > internal class Program { static object _lock = new object(); static void Main(string[] args) { <span style='color: blue; font-weight: bold'>lock (_lock)</span> { <span style='color: blue; font-weight: bold'>Monitor.Pulse(_lock); Debugger.Break();</span> } } } </pre> <br /> lock (_lock) 코드로 인해 잠깐 thinlock이 생겼다가, Monitor.Pulse 호출 이후에는 syncblk이 생성되는 것을 볼 수 있습니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 0:000> <span style='color: blue; font-weight: bold'>!dumpheap -thinlock</span> Address MT Size Found 0 objects. 0:000> <span style='color: blue; font-weight: bold'>!syncblk</span> 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 </pre> <br /> 이렇게 생긴 syncblk은 lock (...) 블록을 벗어나야 없어집니다. 결국, lock + Wait과는 달리 lock + Pulse는 다른 스레드의 lock 진입을 막으므로 가능한 한 빨리 블록을 빠져나오도록 해야 합니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 정리해 보면, Monitor.Wait으로 인한 스레드 대기 현상은 메모리 덤프 파일로부터 관련 정보를 찾아내기가 매우 힘들다는 특징이 있습니다. 물론, Wait과 Pulse(All) 쌍은 대부분의 경우 <a target='tab' href='https://www.sysnet.pe.kr/2/0/1015'>Producer/Consumer 모델</a>에서 사용하므로 딱히 Wait 대기 상태를 풀어줄 스레드를 굳이 찾아내야 할 필요는 거의 없습니다.<br /> <br /> 반면, Wait/Pulse(All)를 lock(obj) 형태처럼 동작해야 할 코드에 응용하는 것은 자칫 디버깅을 힘들게 할 수 있으므로 사용 시 주의를 기울이는 것이 좋습니다.<br /> </p><br /> <br /> <br /><hr /><span style='color: Maroon'>[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]</span> </div>
첨부파일
스팸 방지용 인증 번호
1510
(왼쪽의 숫자를 입력해야 합니다.)