C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리
문서를 하나 읽다가 문득 아래의 문구에 꽂혔습니다. ^^
Interrupt can interrupt threads that are waiting to enter a lock. On Windows STA threads, waits for locks allow message pumping that can run other code on the same thread during a wait. Some features of the waits can be overridden by a custom SynchronizationContext.
일단, 저 문장을 시작하게 된
Interrupt에 대해서는 전에도 한 번 다룬 적이 있으니 넘어가겠습니다.
재미있는 건 그다음인데요, STA 스레딩 모델일 때 잠금에 대한 대기를 하는 동안 Win32 메시지 루프가 동작할 수 있다는 것입니다. 좀 더 찾아보면,
Which blocking operations cause an STA thread to pump COM messages?
; https://stackoverflow.com/questions/21571598/which-blocking-operations-cause-an-sta-thread-to-pump-com-messages
Is there a way to WAIT for a thread to complete processing while pumping windows messages?
; https://stackoverflow.com/questions/4540244/how-is-this-possible-onpaint-processed-while-in-waitone/4540745#4540745
다음의 메서드는 메시지 펌프 처리를 허용하는 반면,
- Thread.Join
- WaitHandle.WaitOne/WaitAny/WaitAll (WaitAll cannot be called from an STA thread though)
- GC.WaitForPendingFinalizers
- Monitor.Enter (and therefore lock) - under some conditions
- ReaderWriterLock
- BlockingCollection
Thread.Sleep, Console.ReadKey는 메시지 펌프 처리가 안 된다고 합니다. 하지만, 그렇다고 해서 모든 메시지들이 처리되는 것도 아니고 일부 제한적인 메시지만 처리한다고 하는데요, 정말 그런지 확인해 보고 싶어졌습니다. ^^
우선, 허용하는 메시지로는 (Win32 개발자에게는 친숙할 수밖에 없는) WM_PAINT가 있다고 하는데요, 그럼 이걸로 한 번 테스트를 해보겠습니다.
한 가지 문제가 있다면, (Vista 이후) Windows의 경우
Desktop Composition으로 인해 일단 한 번 윈도우가 화면에 그려졌으면 이후 다른 윈도우에 의해 가려지고 다시 나타났다고 해서 WM_PAINT가 발생하지 않는다는 점입니다.
쉽게 말해 WM_PAINT의 발생이 쉽지 않다는 점인데요, 대신 이걸 강제로 발생시킬 수 있는 방법이 있습니다. 즉, offscreen surface를 소유한 dwm.exe 프로세스를 그냥 작업 관리자를 이용해 강제로 종료하면 이후 dwm.exe가 재시작하면서 offscreen surface를 다시 구하기 위해 반드시 응용 프로그램에는 WM_PAINT를 전송하는 과정을 거치게 될 텐데 그걸 이용하면 됩니다.
자, 그럼 코드로 테스트를 해볼까요? ^^
코드는 Windows Forms 기본 프로젝트를 만들고 Monitor.Enter로 잠금을 유지할 스레드 하나와, 그로 인해 동일한 잠금을 획득할 수 없어 블록킹이 발생하는 코드를 수행하도록 버튼에 이벤트 핸들러를 두는 것으로 재현이 가능합니다.
namespace WinFormsApp1;
public partial class Form1 : Form
{
public const uint WM_PAINT = 0x000F;
static object s_lock = new();
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
new Thread(() =>
{
lock (s_lock)
{
Thread.Sleep(-1); // 잠금 상태 유지
}
})
{ IsBackground = true }.Start();
}
protected override void WndProc(ref Message m)
{
base.WndProc(ref m);
if (m.Msg == WM_PAINT) // WM_PAINT 발생 유무를 확인하기 위한 용도
{
System.Diagnostics.Trace.WriteLine($"{DateTime.Now} - WndProc - WM_PAINT");
}
}
private void button1_Click(object sender, EventArgs e)
{
lock (s_lock) // s_lock을 얻기 위해 무한 대기
{
System.Diagnostics.Trace.WriteLine($"{DateTime.Now} - You will never see this message!");
}
}
}
테스트 순서는 이렇게 하시면 됩니다.
- Visual Studio에서 F5 디버깅 실행
- button1 클릭
- 작업 관리자에서 dwm.exe 강제 종료
- Visual Studio의 Output 창에 "WM_PAINT" 메시지가 출력되는 것을 확인
실제로 해보면 정말 WM_PAINT가 출력되는 것을 확인할 수 있습니다. 게다가 내부의 "그리기" 작업도 끝나 윈도우 화면은 다음과 같이 잘 보입니다.
그렇다면 lock 대신 Thread.Sleep으로 대기를 하도록 바꾸면 어떻게 될까요?
private void button1_Click(object sender, EventArgs e)
{
//lock (s_lock)
//{
// System.Diagnostics.Trace.WriteLine($"{DateTime.Now} - You will never see this message!");
//}
Thread.Sleep(Timeout.Infinite);
}
Q&A 글에 따르면, Thread.Sleep은 메시지 펌핑 처리가 안 된다고 하는데요, 따라서 이전에 수행했던 테스트 과정을 그대로 해보면, Output 창에서 "WM_PAINT" 메시지를 볼 수 없습니다. 게다가 Window 화면도 내부의 "그리기" 작업이 없어 버튼 윈도우 등의 내용이 없습니다.
그다지 유용할 것은 없지만, 테스트를 위한 관련 지식을 통합하는 과정에 묘미가 있을 듯합니다. ^^
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]