Microsoft MVP성태의 닷넷 이야기
Windows: 189. WM_TIMER의 동작 방식 개요 [링크 복사], [링크+제목 복사]
조회: 721
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

WM_TIMER의 동작 방식 개요

아래의 답변을 하다 보니,

Winform timer tick 안에서 enabled 제어
; https://forum.dotnetdev.kr/t/winform-timer-tick-enabled/429

이참에 정리하고 지나가야겠다는 생각이 들어 ^^ 이렇게 별도의 글로 기록을 남깁니다.




제 기억에, 예전에는 상당히 깊은 내용까지 문서로 있었던 것 같은데 근래에는 워낙 응용 레벨의 추상화가 깊어지다 보니 그런 부분까지는 이제 공개를 하지 않는 듯합니다. 어쨌든, 가능한 있는 자료 내에서 인용해보겠습니다.

About Messages and Message Queues - Queued Messages
; https://docs.microsoft.com/en-us/windows/win32/winmsg/about-messages-and-message-queues#queued-messages

In addition, multiple WM_PAINT messages for the same window are combined into a single WM_PAINT message, consolidating all invalid parts of the client area into a single area. Combining WM_PAINT messages reduces the number of times a window must redraw the contents of its client area.


여러 개의 WM_PAINT가 발생하면 하나의 메시지로 합쳐져 처리한다는 식인데요, Raymond Chen의 블로그에서 이에 대한 보다 상세한 설명을 찾아볼 수 있습니다.

Paint messages will come in as fast as you let them
; https://devblogs.microsoft.com/oldnewthing/20111219-00/?p=8863

There is a class of messages which are generated on demand rather than explicitly posted into a message queue. If you call Get­Message or Peek­Message and the queue is empty, then the window manager will look to see if one of these generated-on-demand messages is due, messages like WM_TIMER, WM_MOUSEMOVE, and WM_PAINT.

...

Then a message retrieval function finds that there are no incoming sent messages to be dispatched nor any applicable messages in the queue to be retrieved, it looks at these extra flags to see if it should generate a message on the fly.


(WM_PAINT, WM_MOUSEMOVE도 유사한 방식으로 처리하는데), WM_TIMER의 경우 시스템에 의해 시간이 만료된 경우, 그것을 표현하는 flag를 설정한다고 합니다. (개념상 그렇다는 것이지, 실제로 그렇게 플래그 처리를 하는 방식은 아니라고! 제 기억으로는 얼핏 메시지 큐에도 우선순위별로 나누어져 있다고 했던 글을 본 적이 있는 것 같습니다. 혹시 이에 대한 자세한 이력과 문서를 아시는 분은 덧글 부탁드립니다. ^^)

이후 메시지 루프를 처리하는 GetMessage/PeekMessage가 호출되고, 이때 처리할 메시지가 있다면 그것을 처리하고, 더 이상 처리할 메시지가 없다면 시스템의 timer flag를 보고 그 시점에 WM_TIMER를 생성해 큐에 넣어 자연스럽게 GetMessage/PeekMessage의 호출에서 그 메시지를 수신하게 됩니다.

이러한 설명에 대해서는 다음의 글에서도 하고 있습니다.

Even though mouse-move, paint, and timer messages are generated on demand, it’s still possible for one to end up in your queue
; https://devblogs.microsoft.com/oldnewthing/20130523-00/?p=4273

We all know that the generated-on-demand messages like WM_MOUSE­MOVE, WM_PAINT, and WM_TIMER messages are not posted into the queue when the corresponding event occurs, but rather are generated by Get­Message or Peek­Message when they detect that they are about to conclude that there is no message to return and the generated-on-demand message can be returned.

...

Note that this auto-generate can happen even though the queue is not empty, because the message filters control what messages in the queue can be returned.

...

Note that this algorithm is conceptual. It doesn’t actually work this way internally. In particular, the window manager does not literally talk to itself, at least not out loud.


따라서, 일반적으로는 메시지 큐가 비어 있어야 WM_TIMER, WM_MOUSEMOVE, WM_PAINT 등이 처리되지만 꼭 그런 것만은 아니라고 합니다. 이에 대한 사례가 Message Filter 조건을 걸어 GetMessage/PeekMessage를 호출하는 경우라고 하는데요, 메시지 큐에 이벤트가 있다고 해도 필터 조건에 걸려 반환할 이벤트가 없다면 그런 경우에도 WM_TIMER, WM_MOUSEMOVE, WM_PAINT가 처리될 수 있다고 합니다. (여기서도 다시 한번 강조하지만 개념적으로 그렇다는 것입니다.)

그런데 만약 다른 메시지는 없고 WM_TIMER만 발생하는 환경에서, 메시지 필터링으로 인해 WM_TIMER 처리가 제외된다면 어떻게 될까요? GetMessage/PeekMessage는 계속해서 조건을 만족하는 메시지가 없어 큐가 비어 있는 것과 유사한 동작을 할 것이고, 따라서 WM_TIMER가 지속적으로 메시지 큐에 차서 나중에는 더 이상 큐의 여유 공간이 없는 상황까지 가게 될 것입니다. 실제로 이런 조건이 COM 개체에서 발생할 수 있음을 다음의 글에서 보이고 있습니다.

Why is my message queue full of WM_TIMER messages?
; https://devblogs.microsoft.com/oldnewthing/20160624-00/?p=93745

COM 런타임은 WM_TIMER는 처리하지 않고 WM_SYSTIMER만 처리하므로 결국 COM 환경에서 WM_TIMER를 발생시키면 지속적으로 WM_TIMER 메시지가 큐에 차게 되고, 결국에는 일반 메시지까지 처리할 수 없게 되는 것입니다.

마지막으로 Raymond는 이런 글을 남기는데요,

Can I force a WM_TIMER message to be generated when the timer comes due, even if the message queue is not idle?
; https://devblogs.microsoft.com/oldnewthing/20191108-00/?p=103080

위의 글을 살짝 테스트해 보면 다음과 같은 WinForm 코드를 만들어 볼 수 있습니다.

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace WindowsFormsApp1
{
    public partial class Form1 : Form
    {
        [return: MarshalAs(UnmanagedType.Bool)]
        [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
        internal static extern bool PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);

        Timer _timer;
        System.Threading.Thread _thread;
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            _thread = new System.Threading.Thread(postMessageFunc);
            _thread.Start();

            _timer = new Timer();
            _timer.Interval = 1000;
            _timer.Tick += _timer_Tick;
            _timer.Enabled = true;
        }

        protected override void DefWndProc(ref Message m)
        {
            if (m.Msg == 0x0400 + 1)
            {
                System.Threading.Thread.Sleep(900);
            }

            base.DefWndProc(ref m);
        }

        private void postMessageFunc()
        {
            Control.CheckForIllegalCrossThreadCalls = false;
            while (true)
            {   // WM_USER == 0x0400
                PostMessage(this.Handle, 0x0400 + 1, IntPtr.Zero, IntPtr.Zero);
                System.Threading.Thread.Sleep(800);
            }
        }

        private void _timer_Tick(object sender, EventArgs e)
        {
            System.Diagnostics.Trace.WriteLine(DateTime.Now);
        }
    }
}

위와 같이 실행하면, _timer_Tick 이벤트가 발생하지 않습니다. 왜냐하면 PostMessage가 800ms마다 메시지를 큐에 넣어두고 메시지 큐를 비우는 스레드가 900ms 동안 중지되기 때문에 메시지 큐에는 항상 (WM_USER + 1)에 해당하는 메시지가 놓여 있어 WM_TIMER가 들어올 여지가 없습니다. 그런데, 사실 저 상황에서는 WM_TIMER뿐만 아니라 대부분의 메시지가 처리되지 않습니다. 대신, 저 상태에서 GetMessage/PeekMessage 호출을 추가하면 Raymond Chen이 설명한 "generated-on-demand message"의 처리 방식을 확인할 수는 있습니다. 그래서 다음과 같이 코드를 바꾸면,

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool PeekMessage(out NativeMessage lpMsg, IntPtr hWnd, uint wMsgFilterMin, uint wMsgFilterMax, uint wRemoveMsg);

protected override void DefWndProc(ref Message m)
{
    if (m.Msg == 0x0400 + 1)
    {
        System.Threading.Thread.Sleep(900);

        /* 0x0113 == WM_TIMER */
        /* 0x0000 == PM_NOREMOVE */
        PeekMessage(out NativeMessage msg, IntPtr.Zero, 0x0113, 0x0113, 0x0000);
    }

    base.DefWndProc(ref m);
}

[StructLayout(LayoutKind.Sequential)]
public struct NativeMessage
{
    // ...[생략]...
}

PeekMessage의 Filter 조건으로 인해 WM_TIMER가 메시지 큐에 있는지 확인하지만, 위와 같은 상황에서는 당연히 큐에 없으므로 'timer flag' 설정에 따라 WM_TIMER가 메시지 큐에 새롭게 들어오게 됩니다. 그래서, 디버그 모드로 실행하면 다음과 같은 식의 출력을 확인할 수 있습니다.

2021-02-16 오후 7:11:35
2021-02-16 오후 7:11:49
2021-02-16 오후 7:11:53
2021-02-16 오후 7:11:57
2021-02-16 오후 7:12:02
2021-02-16 오후 7:12:07
2021-02-16 오후 7:12:13
2021-02-16 오후 7:12:20
2021-02-16 오후 7:12:27
2021-02-16 오후 7:12:35
2021-02-16 오후 7:12:44
2021-02-16 오후 7:12:54
2021-02-16 오후 7:13:06
2021-02-16 오후 7:13:19
2021-02-16 오후 7:13:33
2021-02-16 오후 7:13:49
2021-02-16 오후 7:14:08
2021-02-16 오후 7:14:27
2021-02-16 오후 7:14:50
2021-02-16 오후 7:15:16
2021-02-16 오후 7:15:44
2021-02-16 오후 7:16:15
2021-02-16 오후 7:16:51
2021-02-16 오후 7:17:30
2021-02-16 오후 7:18:15
...

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




참고로, 본문에 실은 예제의 경우 계속 실행 상태로 두면 (WM_USER + 1) 메시지가 쌓여 결국에는 60초 동안 응답할 수 없는 상태가 되어 (비주얼 스튜디오의 디버그 모드인 경우) MDA 예외까지 보게 됩니다.

Managed Debugging Assistant 'ContextSwitchDeadlock'
Message=Managed Debugging Assistant 'ContextSwitchDeadlock' : 'The CLR has been unable to transition from COM context 0x83004a80 to COM context 0x83004958 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.'




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

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 3/28/2021

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)
12610정성태4/22/2021336.NET Framework: 1046. C# - 컴파일 시점에 참조할 수 없는 타입을 포함한 이벤트 핸들러를 Reflection을 이용해 구독하는 방법파일 다운로드1
12609정성태4/22/2021431.NET Framework: 1045. C# - 런타임 시점에 이벤트 핸들러를 만들어 Reflection을 이용해 구독하는 방법파일 다운로드1
12608정성태4/21/2021582.NET Framework: 1044. C# - Generic Host를 이용해 .NET 5로 리눅스 daemon 프로그램 만드는 방법 [7]파일 다운로드1
12607정성태4/21/2021413.NET Framework: 1043. C# - 실행 시점에 동적으로 Delegate 타입을 만드는 방법파일 다운로드1
12606정성태4/21/2021435.NET Framework: 1042. C# - enum 값을 int로 암시적(implicit) 형변환하는 방법? [2]파일 다운로드1
12605정성태4/18/2021349.NET Framework: 1041. C# - AssemblyID, ModuleID를 관리 코드에서 구하는 방법파일 다운로드1
12604정성태4/18/2021321VS.NET IDE: 163. 비주얼 스튜디오 속성 창의 "Build(빌드)" / "Configuration(구성)"에서의 "활성" 의미
12603정성태4/16/2021374VS.NET IDE: 162. 비주얼 스튜디오 - 상속받은 컨트롤이 디자인 창에서 지원되지 않는 문제
12602정성태4/16/2021503VS.NET IDE: 161. x64 DLL 프로젝트의 컨트롤이 Visual Studio의 Designer에서 보이지 않는 문제
12601정성태4/15/2021330.NET Framework: 1040. C# - REST API 대신 github 클라이언트 라이브러리를 통해 프로그래밍으로 접근
12600정성태4/15/2021318.NET Framework: 1039. C# - Kubeconfig의 token 설정 및 인증서 구성을 자동화하는 프로그램
12599정성태4/14/2021307.NET Framework: 1038. C# - 인증서 및 키 파일로부터 pfx/p12 파일을 생성하는 방법파일 다운로드1
12598정성태4/14/2021332.NET Framework: 1037. openssl의 PEM 개인키 파일을 .NET RSACryptoServiceProvider에서 사용하는 방법 (2)파일 다운로드1
12597정성태4/13/2021304개발 환경 구성: 569. csproj의 내용을 공통 설정할 수 있는 Directory.Build.targets / Directory.Build.props 파일
12596정성태4/12/2021360개발 환경 구성: 568. Windows의 80 포트 점유를 해제하는 방법
12595정성태4/12/2021313.NET Framework: 1036. SQL 서버 - varbinary 타입에 대한 문자열의 CAST, CONVERT 변환을 C# 코드로 구현
12594정성태4/11/2021444.NET Framework: 1035. C# - kubectl 명령어 또는 REST API 대신 Kubernetes 클라이언트 라이브러리를 통해 프로그래밍으로 접근 [1]파일 다운로드1
12593정성태4/10/2021376개발 환경 구성: 567. Docker Desktop for Windows - kubectl proxy 없이 k8s 대시보드 접근 방법
12592정성태4/10/2021329개발 환경 구성: 566. Docker Desktop for Windows - k8s dashboard의 Kubeconfig 로그인 및 Skip 방법
12591정성태4/9/2021588.NET Framework: 1034. C# - byte 배열을 Hex(16진수) 문자열로 고속 변환하는 방법파일 다운로드1
12590정성태4/9/2021330.NET Framework: 1033. C# - .NET 4.0 이하에서 Console.IsInputRedirected 구현
12589정성태4/8/2021356.NET Framework: 1032. C# - Environment.OSVersion의 문제점 및 윈도우 운영체제의 버전을 구하는 다양한 방법
12588정성태4/7/2021328개발 환경 구성: 565. PowerShell - New-SelfSignedCertificate를 사용해 CA 인증서 생성 및 인증서 서명 방법
12587정성태4/6/2021477개발 환경 구성: 564. Windows 10 - ClickOnce 배포처럼 사용할 수 있는 MSIX 설치 파일
12586정성태4/5/2021298오류 유형: 710. Windows - Restart-Computer / shutdown 명령어 수행 시 Access is denied(E_ACCESSDENIED)
12585정성태4/5/2021296개발 환경 구성: 563. 기본 생성된 kubeconfig 파일의 내용을 새롭게 생성한 인증서로 구성하는 방법
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...