Microsoft MVP성태의 닷넷 이야기
Windows: 189. WM_TIMER의 동작 방식 개요 [링크 복사], [링크+제목 복사]
조회: 954
글쓴 사람
정성태 (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)
12640정성태5/13/2021666오류 유형: 716. RDP 연결 - Because of a protocol error (code: 0x112f), the remote session will be disconnected. [1]
12639정성태5/12/2021457오류 유형: 715. Arduino: Open Serial Monitor - The module '...\detection.node' was compiled against a different Node.js version using NODE_MODULE_VERSION
12638정성태5/12/2021506사물인터넷: 63. NodeMCU v1 ESP8266 - 펌웨어 내 파일 시스템(SPIFFS, LittleFS) 및 EEPROM 활용
12637정성태5/10/2021500사물인터넷: 62. NodeMCU v1 ESP8266 보드의 A0 핀에 다중 아날로그 센서 연결 [1]
12636정성태5/10/2021569사물인터넷: 61. NodeMCU v1 ESP8266 보드의 A0 핀 사용법 - FSR-402 아날로그 압력 센서 연동파일 다운로드1
12635정성태5/9/2021454기타: 81. OpenTabletDriver를 (관리자 권한으로 실행하지 않고도) 관리자 권한의 프로그램에서 동작하게 만드는 방법
12634정성태5/9/2021531개발 환경 구성: 572. .NET에서의 신뢰도 등급 조정 - 외부 Manifest 파일을 두는 방법파일 다운로드1
12633정성태5/7/2021523개발 환경 구성: 571. UAC - 관리자 권한 없이 UIPI 제약을 없애는 방법
12632정성태5/7/2021575기타: 80. (WACOM도 지원하는) Tablet 공통 디바이스 드라이버 - OpenTabletDriver
12631정성태5/5/2021524사물인터넷: 60. ThingSpeak 사물인터넷 플랫폼에 ESP8266 NodeMCU v1 + 조도 센서 장비 연동파일 다운로드1
12630정성태5/5/2021570사물인터넷: 59. NodeMCU v1 ESP8266 보드의 A0 핀 사용법 - CdS Cell(GL3526) 조도 센서 연동파일 다운로드1
12629정성태5/5/2021715.NET Framework: 1057. C# - CoAP 서버 및 클라이언트 제작 (UDP 소켓 통신)파일 다운로드1
12628정성태5/4/2021506Linux: 39. Eclipse 원격 디버깅 - Cannot run program "gdb": Launching failed
12627정성태5/4/2021527Linux: 38. 라즈베리 파이 제로 용 프로그램 개발을 위한 Eclipse C/C++ 윈도우 환경 설정
12626정성태5/3/2021525.NET Framework: 1056. C# - Thread.Suspend 호출 시 응용 프로그램 hang 현상 (2)파일 다운로드1
12625정성태5/3/2021604오류 유형: 714. error CS5001: Program does not contain a static 'Main' method suitable for an entry point
12624정성태5/2/2021761.NET Framework: 1055. C# - struct/class가 스택/힙에 할당되는 사례 정리 [6]파일 다운로드1
12623정성태5/2/2021571.NET Framework: 1054. C# 9 최상위 문에 STAThread 사용파일 다운로드1
12622정성태5/2/2021419오류 유형: 713. XSD 파일을 포함한 프로젝트 - The type or namespace name 'TypedTableBase<>' does not exist in the namespace 'System.Data'
12621정성태5/1/2021763.NET Framework: 1053. C# - 특정 레지스트리 변경 시 알림을 받는 방법파일 다운로드1
12620정성태4/29/2021988.NET Framework: 1052. C# - 왜 구조체는 16 바이트의 크기가 적합한가? [1]파일 다운로드1
12619정성태4/28/2021866.NET Framework: 1051. C# - 구조체의 크기가 16바이트가 넘어가면 힙에 할당된다? [1]파일 다운로드1
12618정성태4/27/2021561사물인터넷: 58. NodeMCU v1 ESP8266 CP2102 Module을 이용한 WiFi UDP 통신파일 다운로드1
12617정성태4/26/2021506.NET Framework: 1050. C# - ETW EventListener의 Keywords별 EventId에 따른 필터링 방법파일 다운로드1
12616정성태4/26/2021509.NET Framework: 1049. C# - ETW EventListener를 상속받았을 때 초기화 순서파일 다운로드1
12615정성태4/26/2021396오류 유형: 712. Microsoft Live 로그인 - 계정을 선택하는(Pick an account) 화면에서 진행이 안 되는 문제
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...