반응형
이 글은 Code Project에 있는 Timers Tutorial을 정리한 것입니다.
우선, 윈도우는 윈도우 CE를 제외하면 리얼타임OS가 아닌 관계로 10ms와 같은 매우 작은 시간에 대한 정확한 처리를 요구하는 건 한계가 있답니다. (쥔장도 자세한 이유는 잘... 흠...) QueryPerformanceFrequency나 QueryPerformanceCounter와 같은 경우는 특정 시간 경과 후 이벤트를 처리하는 것이 주요 쓰임이 아니라 시간과 시간사이의 시간차를 계산하는 것이 주요 쓰임인 관계로 이 글에서는 언급되어 있지 않습니다. 반대로 말하면 시간과 시간사이의 차이를 정확히 측정하려면 QueryPerformanceFrequency를 사용하여야 겠죠?
1. Standard Win32 Timer (표준 윈32 타이머)
Win32 UI프로그래밍 처음 배우면 사용하는 WM_TIMER 메시지 관련된 API를 사용하는 것입니다. 시간 정확도가 떨어지지만 몇분에 한번과 같이 느슨하게 처리할 때 사용하면 좋습니다. 처리방식은 Win32의 윈도우 메시지 큐를 사용하며 callback 함수를 이용하는 경우는 WM_TIMER 메시지를 큐에서 끄내는 대신 함수를 콜하는 방식이라 메시지 방식과 큰 차이를 보이지 않습니다. 중요한 점은 WM_TIMER 메시지를 처리하는 동안 UI의 반응성이 나뻐질 수 있다는 것입니다.
2. Multimedia Timers (멀티미디어 타이머)
많이 사용되는 이유는 호환성 때문이며 최근에는 비권장되는 방식입니다. 표준 윈32 타이머보다 정확한 처리를 하며 자신의 쓰레드에서 동작합니다. 이 방식은 짧은 진행시간을 지정하였을 때는 메시지 큐의 보호를 받지 못하므로 조금 더 위험하다는데 자세한 이유가 나와 있지는 않습니다. (지송합니다. 쥔장이 현재 구지 쓸 이유가 없기 때문에 자세한 이유는 찾아보지 않았습니다. 원문에는 관련 블로그 포스트가 링크되어 있으므로 관심 있는 분은 한 번 찾아보기 바랍니다.)
3. Waitable Timers
적은 CPU 점유율을 가지면 메시지 큐를 가지지 않는 장점이 있지만 호출하는 쓰레드를 블록시키며 alertable상태로 만들어야 합니다. APC(Asynchronous Procedure Call)로 동작합니다.
4. Queue Timers
현재 최고 성능의 타이머 있데 아쉽게도 윈도우2000이후 버전만을 지원합니다. 이 API는 윈도우 쓰레드풀에서 작동하며 굉장히 정확하게 작동합니다. 저자가 강력하게 추천하는 API입니다.
API 선택가이드
1. GUI에서 사용하며, 높은 정확도를 요구하지 않는 경우 표준 윈32 타이머가 좋은 선택입니다.
2. 높은 호환성과 높은 정확도를 원하면 멀티미디어 타이머가 좋은 선택입니다.
3. 윈도우 98/NT4.0 이후 버전만을 대상으로 하며 적은 오버헤드를 가지며 호출쓰레드가 블록되는 것이 괜찮다면 Waitable Timer가 좋은 선택입니다.
4. 윈도우 2K 이후 버전만을 대상으로 하며 적은 호버헤드, 높은 정확성, 논블록킹 타이머를 원한다면 Queue Timer가 좋은 선택입니다. 아마도 MS는 현재 이 Timer를 밀고 있는 듯 싶군요... 흠...
우선, 윈도우는 윈도우 CE를 제외하면 리얼타임OS가 아닌 관계로 10ms와 같은 매우 작은 시간에 대한 정확한 처리를 요구하는 건 한계가 있답니다. (쥔장도 자세한 이유는 잘... 흠...) QueryPerformanceFrequency나 QueryPerformanceCounter와 같은 경우는 특정 시간 경과 후 이벤트를 처리하는 것이 주요 쓰임이 아니라 시간과 시간사이의 시간차를 계산하는 것이 주요 쓰임인 관계로 이 글에서는 언급되어 있지 않습니다. 반대로 말하면 시간과 시간사이의 차이를 정확히 측정하려면 QueryPerformanceFrequency를 사용하여야 겠죠?
1. Standard Win32 Timer (표준 윈32 타이머)
Win32 UI프로그래밍 처음 배우면 사용하는 WM_TIMER 메시지 관련된 API를 사용하는 것입니다. 시간 정확도가 떨어지지만 몇분에 한번과 같이 느슨하게 처리할 때 사용하면 좋습니다. 처리방식은 Win32의 윈도우 메시지 큐를 사용하며 callback 함수를 이용하는 경우는 WM_TIMER 메시지를 큐에서 끄내는 대신 함수를 콜하는 방식이라 메시지 방식과 큰 차이를 보이지 않습니다. 중요한 점은 WM_TIMER 메시지를 처리하는 동안 UI의 반응성이 나뻐질 수 있다는 것입니다.
- SetTimer(...)
- KillTimer(...)
2. Multimedia Timers (멀티미디어 타이머)
많이 사용되는 이유는 호환성 때문이며 최근에는 비권장되는 방식입니다. 표준 윈32 타이머보다 정확한 처리를 하며 자신의 쓰레드에서 동작합니다. 이 방식은 짧은 진행시간을 지정하였을 때는 메시지 큐의 보호를 받지 못하므로 조금 더 위험하다는데 자세한 이유가 나와 있지는 않습니다. (지송합니다. 쥔장이 현재 구지 쓸 이유가 없기 때문에 자세한 이유는 찾아보지 않았습니다. 원문에는 관련 블로그 포스트가 링크되어 있으므로 관심 있는 분은 한 번 찾아보기 바랍니다.)
- timeGetDevCaps(...)
- timeBeginPeriod(...)
- timeSetEvent(...)
- TimeProc(...)
- timeKillEvent(...)
- timeEndPeriod(...)
3. Waitable Timers
적은 CPU 점유율을 가지면 메시지 큐를 가지지 않는 장점이 있지만 호출하는 쓰레드를 블록시키며 alertable상태로 만들어야 합니다. APC(Asynchronous Procedure Call)로 동작합니다.
- CreateWaitableTimer(...)
- SetWaitableTimer(...)
- CancelWaitableTimer(...)
Alerable 관련 함수
- SleepEx(...)
- WaitForSingleObjectEx(...)
- WaitForMultipleObjectsEx(...)
- MsgWaitForMultipleObjectsEx(...)
- SignalObjectAndWait(...)
4. Queue Timers
현재 최고 성능의 타이머 있데 아쉽게도 윈도우2000이후 버전만을 지원합니다. 이 API는 윈도우 쓰레드풀에서 작동하며 굉장히 정확하게 작동합니다. 저자가 강력하게 추천하는 API입니다.
- CreateTimerQueueTimer(...)
- WaitOrTimerCallback(...)
- DeleteTimerQueueTimer(...)
API 선택가이드
1. GUI에서 사용하며, 높은 정확도를 요구하지 않는 경우 표준 윈32 타이머가 좋은 선택입니다.
2. 높은 호환성과 높은 정확도를 원하면 멀티미디어 타이머가 좋은 선택입니다.
3. 윈도우 98/NT4.0 이후 버전만을 대상으로 하며 적은 오버헤드를 가지며 호출쓰레드가 블록되는 것이 괜찮다면 Waitable Timer가 좋은 선택입니다.
4. 윈도우 2K 이후 버전만을 대상으로 하며 적은 호버헤드, 높은 정확성, 논블록킹 타이머를 원한다면 Queue Timer가 좋은 선택입니다. 아마도 MS는 현재 이 Timer를 밀고 있는 듯 싶군요... 흠...
반응형
'윈도우 프로그래밍' 카테고리의 다른 글
Low Fragementation Heap(LFH) (0) | 2009.07.03 |
---|---|
Win32 ThreadPool (0) | 2009.07.03 |
OLE DB의 클래스 역활 (0) | 2009.06.14 |
Fiber [beta] (0) | 2009.05.13 |
UDP, recvfrom()에서 WSAECONNRESET(10054) 에러 날 때... (0) | 2009.04.30 |
SetEvent(..) & 멀티쓰레드 버그 (0) | 2009.04.28 |
First Chance Exception (0) | 2009.04.24 |
Lua R6034 Runtime Error in Visual Studio 2008 in Vista (0) | 2009.04.18 |