Microsoft MVP성태의 닷넷 이야기
.NET Framework: 2019. C# - .NET에서 제공하는 3가지 Timer 비교 [링크 복사], [링크+제목 복사],
조회: 9531
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 5개 있습니다.)
.NET Framework: 486. Java의 ScheduledExecutorService에 대응하는 C#의 System.Threading.Timer
; https://www.sysnet.pe.kr/2/0/1823

VC++: 103. C++ CreateTimerQueue, CreateTimerQueueTimer 예제 코드
; https://www.sysnet.pe.kr/2/0/11090

.NET Framework: 636. System.Threading.Timer를 이용해 타이머 작업을 할 때 유의할 점
; https://www.sysnet.pe.kr/2/0/11134

Windows: 189. WM_TIMER의 동작 방식 개요
; https://www.sysnet.pe.kr/2/0/12539

.NET Framework: 2019. C# - .NET에서 제공하는 3가지 Timer 비교
; https://www.sysnet.pe.kr/2/0/13069




C# - .NET에서 제공하는 3가지 Timer 비교

2022년인데, 여전히 헷갈려 하시는 분들이 있어서 2004년도에 쓰인 글임에도 정리해 둘 필요가 있군요. ^^

Timers - Comparing the Timer Classes in the .NET Framework Class Library
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2004/february/comparing-the-timer-classes-in-the-net-framework-class-library




대표적으로, 닷넷에서 쉽게 쓸 수 있는 타이머는 다음과 같이 3가지 유형입니다.

  1. System.Windows.Forms.Timer
  2. System.Threading.Timer
  3. System.Timers.Timer

하나씩 알아볼까요? ^^


System.Windows.Forms.Timer

Windows Forms 응용 프로그램 유형에서 일반적으로 쉽게 쓸 수 있는 타이머인데요, 사실 이것은 Win32 API 시절에 사용하던 WM_TIMER 이벤트 처리와 동일합니다.

WM_TIMER
; https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-timer

System.Windows.Forms.Timer가 갖는 가장 큰 차이점은 바로, Timer 발생 시 실행되는 callback 이벤트 핸들러가 Windows Forms의 UI 스레드에 의해 실행된다는 점입니다.

private void timer1_Tick(object sender, EventArgs e)
{
    this.textBox1.Text = $"{DateTime.Now}"; // UI 요소 접근 가능
}

달리 말하면, 결국 Windows Message를 처리하는 메시지 루프가 있어야 하기 때문에 Console Application 등의 환경에서는 사용할 수 없다는 제약이 있습니다. (물론, Console 유형에서도 메시지 루프를 구현하면 사용할 수 있습니다.)

참고로, Visual Studio는 이 타이머를 "도구 상자(Toolbox)"에서도 제공해 Forms 위에 drag&drop 하는 식으로 사용하는 것도 가능합니다.




System.Threading.Timer

System.Threading.Timer는 네임스페이스가 다소 혼란스러울 수 있는데 "System.Threading"이라고 해서 전용 스레드를 생성하는 것은 아니고 스레드 풀을 이용해 callback을 호출하는 방식입니다. 그리고 이 동작 방식의 근간에는 Win32 API인 TimerQueueTimer가 있습니다.

결국, System.Windows.Forms.Timer와는 다르게 메시지 루프가 필요 없으므로 Console Application 등의 유형에서도 잘 동작합니다.

internal class Program
{
    static void Main(string[] args)
    {
        System.Threading.Timer timer = new Timer(timer_Tick, null, 0, 1000);

        Console.ReadLine();
    }

    static void timer_Tick(object? state)
    {
        Console.WriteLine($"{DateTime.Now}");
    }
}

그러니까, 위의 코드에서 timer_Tick 이벤트 핸들러를 실행하는 스레드는 스레드 풀로부터 선택된 스레드인 것입니다. 달리 말하면, 만약 System.Threading.Timer를 Windows Forms와 같은 응용 프로그램에서 사용하는 경우 그것의 이벤트 핸들러에서는 UI 요소를 접근 시 별도 처리(InvokeRequired/BeginInvoke)가 필요하게 됩니다.

또 한 가지 주요 차이점은, timer 콜백이 밀리지 않는다는 특징도 있습니다. 가령, System.Windows.Forms.Timer의 경우 해당 이벤트 핸들러에서 다음과 같은 식으로 Thread.Sleep을 주면,

// System.Windows.Forms.Timer
// 타이머가 1초마다 발생하도록 설정된 상황에서,
private void timer1_Tick(object sender, EventArgs e)
{
    this.textBox1.Text = $"{DateTime.Now}";
    Thread.Sleep(1000 * 3); // 또는, 이에 준하는 코드를 수행하는 경우    
}

타이머 자체는 1초마다 발생하도록 설정했지만, 그것의 Tick 핸들러에서 3초를 지연하는 바람에 다음번 timer1_Tick 이벤트는 지난 메시지 출력에서 3초가 걸린 이후가 됩니다. (이러한 동작의 이면에는 WM_TIMER의 특별 대우가 있긴 합니다.)

반면, System.Threading.Timer를 사용한 이벤트 핸들러는,

// System.Threading.Timer
// 타이머가 1초마다 발생하도록 설정된 상황에서,
static void timer_Tick(object? state)
{
    Console.WriteLine($"{DateTime.Now}");
    Thread.Sleep(1000 * 3);
}

1초마다 스레드 풀로부터 여유 있는 스레드를 하나씩 선택해 밀리지 않고 timer_Tick 이벤트 핸들러를 계속 수행합니다.




System.Timers.Timer

사실, 대부분의 경우에 여러분들은 System.Windows.Forms.Timer 또는 System.Threading.Timer 둘 중의 하나를 선택하기만 하면 됩니다.

왜냐하면, 마지막으로 설명할 System.Timers.Timer도 위에서 설명한 System.Threading.Timer와 동일하게 Win32 API인 TimerQueueTimer를 기반으로 하기 때문에 동작 방식이 동일합니다. 단지 그 둘 간의 차이점은 다음과 같이 축약/정리할 수 있습니다.

  • System.Threading.Timer: 기본적인 Timer 기능만 제공
  • System.Timers.Timer: System.Threading.Timer에 부가적인 몇 가지 도우미 기능을 추가

즉, "부가적인 기능"을 쓰지 않는다면 그냥 System.Threading.Timer와 System.Timers.Timer는 완전히 동일하다고 봐야 합니다.

그렇다면 어떤 부가 기능이 있을까요?

아마도 "Timers - Comparing the Timer Classes in the .NET Framework Class Library" 글이 쓰인 시점에는 비주얼 스튜디오 도구 상자의 "Windows Forms" 탭에는 System.Windows.Forms.Timer를, "Components" 탭에는 System.Timers.Timer를 보여줬던 것 같습니다.

timer3_diff_0.gif

하지만, 이 둘 간의 차이점을 모르고 실수로 선택한 사례가 많았던 탓인지 이제는 비주얼 스튜디오 도구 상자의 Timer를 "System.Windows.Forms.Timer"로만 보여줍니다.

timer3_diff_1.png

그러니까, System.Timers.Timer는 (아마도 지금 개발자들은 거의 사용하지 않을) "System.ComponentModel.Component"와 연동이 될 수 있는 부가 기능을 갖고 있는 것입니다.

이 외에도, "Timers - Comparing the Timer Classes in the .NET Framework Class Library" 글의 "Figure 7"에 각각의 타이머에 대한 비교가 있습니다. 그중에서 System.Threading.Timer에는 없고 System.Timers.Timer에만 있는 기능을 이렇게 뽑을 수 있습니다.

  • (SynchronizingObject를 설정하면) UI 스레드를 경유해 이벤트 핸들러를 실행 (즉, System.Windows.Forms.Timer와 유사하게 동작 가능)
  • thread-safe
  • 상속 가능

이 외에도 세세하게 다른 면들이 있지만, 이전에 언급한 것처럼 그런 기능의 차이점을 인식하지 않은 상태라면 애당초 System.Windows.Forms.Timer나 System.Threading.Timer 둘 중의 하나를 선택하는 것이 더 직관적일 것입니다.




참고로, System.Threading.Timer와 System.Timers.Timer의 근간을 이루는 TimerQueueTimer 관련해 예전에 써둔 글이 있군요. ^^

C++ CreateTimerQueue, CreateTimerQueueTimer 예제 코드
; https://www.sysnet.pe.kr/2/0/11090

Java의 ScheduledExecutorService에 대응하는 C#의 System.Threading.Timer
; https://www.sysnet.pe.kr/2/0/1823




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/25/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2023-09-24 01시10분
선생님, 아래 문장에 오타 있습니다!
이벤트 핸들러에서는 UI 요소를 접근 시 별도 처리(InvokeRquired/BeginInvoke)가 필요하게 됩니다.
InvokeRquired(e가 빠짐) → InvokeRequired
한예지
2023-09-25 10시52분
감사합니다. 오타 수정했습니다. ^^;
정성태

... 16  17  18  19  20  21  22  23  24  25  26  27  28  29  [30]  ...
NoWriterDateCnt.TitleFile(s)
12883정성태12/19/20217719오류 유형: 775. uwsgi-plugin-python3 환경에서 "ModuleNotFoundError: No module named 'django'" 오류 발생
12882정성태12/18/20216822개발 환경 구성: 619. Windows Server에서 WSL을 위한 리눅스 배포본을 설치하는 방법
12881정성태12/17/20217310개발 환경 구성: 618. WSL Ubuntu 20.04에서 파이썬을 위한 uwsgi 설치 방법 (2)
12880정성태12/16/20217117VS.NET IDE: 170. Visual Studio에서 .NET Core/5+ 역어셈블 소스코드 확인하는 방법
12879정성태12/16/202113368오류 유형: 774. Windows Server 2022 + docker desktop 설치 시 WSL 2로 선택한 경우 "Failed to deploy distro docker-desktop to ..." 오류 발생
12878정성태12/15/20218411개발 환경 구성: 617. 윈도우 WSL 환경에서 같은 종류의 리눅스를 다중으로 설치하는 방법
12877정성태12/15/20217084스크립트: 36. 파이썬 - pymysql 기본 예제 코드
12876정성태12/14/20216917개발 환경 구성: 616. Custom Sources를 이용한 Azure Monitor Metric 만들기
12875정성태12/13/20216613스크립트: 35. python - time.sleep(...) 호출 시 hang이 걸리는 듯한 문제
12874정성태12/13/20216599오류 유형: 773. shell script 실행 시 "$'\r': command not found" 오류
12873정성태12/12/20217745오류 유형: 772. 리눅스 - PATH에 등록했는데도 "command not found"가 나온다면?
12872정성태12/12/20217577개발 환경 구성: 615. GoLang과 Python 빌드가 모두 가능한 docker 이미지 만들기
12871정성태12/12/20217665오류 유형: 771. docker: Error response from daemon: OCI runtime create failed
12870정성태12/9/20216222개발 환경 구성: 614. 파이썬 - PyPI 패키지 만들기 (4) package_data 옵션
12869정성태12/8/20218512개발 환경 구성: 613. git clone 실행 시 fingerprint 묻는 단계를 생략하는 방법
12868정성태12/7/20217081오류 유형: 770. twine 업로드 시 "HTTPError: 400 Bad Request ..." 오류 [1]
12867정성태12/7/20216755개발 환경 구성: 612. 파이썬 - PyPI 패키지 만들기 (3) entry_points 옵션
12866정성태12/7/202114137오류 유형: 769. "docker build ..." 시 "failed to solve with frontend dockerfile.v0: failed to read dockerfile ..." 오류
12865정성태12/6/20216835개발 환경 구성: 611. 파이썬 - PyPI 패키지 만들기 (2) long_description, cmdclass 옵션
12864정성태12/6/20215287Linux: 46. WSL 환경에서 find 명령을 사용해 파일을 찾는 방법
12863정성태12/4/20217205개발 환경 구성: 610. 파이썬 - PyPI 패키지 만들기
12862정성태12/3/20215932오류 유형: 768. Golang - 빌드 시 "cmd/go: unsupported GOOS/GOARCH pair linux /amd64" 오류
12861정성태12/3/20218148개발 환경 구성: 609. 파이썬 - "Windows embeddable package"로 개발 환경 구성하는 방법
12860정성태12/1/20216271오류 유형: 767. SQL Server - 127.0.0.1로 접속하는 경우 "Access is denied"가 발생한다면?
12859정성태12/1/202112427개발 환경 구성: 608. Hyper-V 가상 머신에 Console 모드로 로그인하는 방법
12858정성태11/30/20219702개발 환경 구성: 607. 로컬의 USB 장치를 원격 머신에 제공하는 방법 - usbip-win
... 16  17  18  19  20  21  22  23  24  25  26  27  28  29  [30]  ...