Microsoft MVP성태의 닷넷 이야기
Windows: 189. WM_TIMER의 동작 방식 개요 [링크 복사], [링크+제목 복사]
조회: 420
글쓴 사람
정성태 (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)
12594정성태4/11/202147.NET Framework: 1035. C# - kubectl 명령어 또는 REST API 대신 Kubernets 클라이언트 라이브러리를 통해 프로그래밍으로 접근파일 다운로드1
12593정성태4/10/202124개발 환경 구성: 567. Docker Desktop for Windows - kubectl proxy 없이 k8s 대시보드 접근 방법
12592정성태4/10/202142개발 환경 구성: 566. Docker Desktop for Windows - k8s dashboard의 Kubeconfig 로그인 및 Skip 방법
12591정성태4/9/202183.NET Framework: 1034. C# - byte 배열을 Hex(16진수) 문자열로 고속 변환하는 방법파일 다운로드1
12590정성태4/9/202148.NET Framework: 1033. C# - .NET 4.0 이하에서 Console.IsInputRedirected 구현
12589정성태4/8/202164.NET Framework: 1032. C# - Environment.OSVersion의 문제점 및 윈도우 운영체제의 버전을 구하는 다양한 방법
12588정성태4/7/202155개발 환경 구성: 565. PowerShell - New-SelfSignedCertificate를 사용해 CA 인증서 생성 및 인증서 서명 방법
12587정성태4/7/202183개발 환경 구성: 564. Windows 10 - ClickOnce 배포처럼 사용할 수 있는 MSIX 설치 파일
12586정성태4/5/202151오류 유형: 710 . Windows - Restart-Computer / shutdown 명령어 수행 시 Access is denied(E_ACCESSDENIED)
12585정성태4/5/202149개발 환경 구성: 563. 기본 생성된 kubeconfig 파일의 내용을 새롭게 생성한 인증서로 구성하는 방법
12584정성태4/5/202174개발 환경 구성: 562. kubeconfig 파일 없이 kubectl 옵션만으로 실행하는 방법
12583정성태3/29/2021129개발 환경 구성: 561. kubectl 수행 시 다른 k8s 클러스터로 접속하는 방법
12582정성태3/29/202156오류 유형: 709. Visual C++ - 컴파일 에러 error C2059: syntax error: '__stdcall'
12581정성태3/28/2021238.NET Framework: 1031. WinForm/WPF에서 Console 창을 띄워 출력하는 방법 (2) - Output 디버깅 출력을 AllocConsole로 우회 [2]
12580정성태3/28/202152오류 유형: 708. SQL Server Management Studio - Execution Timeout Expired.
12579정성태3/28/202163오류 유형: 707. 중첩 가상화(Nested Virtualization) - The virtual machine could not be started because this platform does not support nested virtualization.
12578정성태3/27/2021136개발 환경 구성: 560. Docker Desktop for Windows 기반의 Kubernetes 구성 (2) - WSL 2 인스턴스에 kind가 구성한 k8s 서비스 위치
12577정성태3/29/2021169개발 환경 구성: 559. Docker Desktop for Windows 기반의 Kubernetes 구성 - WSL 2 인스턴스에 kind 도구로 k8s 클러스터 구성
12576정성태3/25/2021164개발 환경 구성: 558. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 (2) - k8s 서비스 위치
12575정성태3/24/2021143개발 환경 구성: 557. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성
12574정성태3/28/2021198.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드)
12573정성태4/1/202187개발 환경 구성: 556. WSL 인스턴스 초기 설정 명령어
12572정성태3/28/2021164.NET Framework: 1029. C# - GC 호출로 인한 메모리 압축(Compaction)을 확인하는 방법파일 다운로드1
12571정성태4/1/2021176오류 유형: 706. WSL 2 기반으로 "Enable Kubernetes" 활성화 시 초기화 실패 [1]
12570정성태4/7/2021112개발 환경 구성: 555. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...