Microsoft MVP성태의 닷넷 이야기
닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인 [링크 복사], [링크+제목 복사]
조회: 1642
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 3개 있습니다.)
닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인
; https://www.sysnet.pe.kr/2/0/13570

닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인
; https://www.sysnet.pe.kr/2/0/13571

닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상
; https://www.sysnet.pe.kr/2/0/13572




C# - await 호출과 WPF의 Dispatcher Queue 동작 확인

지난 글에서,

C# - WPF의 Dispatcher Queue 동작 확인
; https://www.sysnet.pe.kr/2/0/13570

Dispatcher에 대한 Invoke... 유의 메서드 실행에 따른 동작을 확인했습니다. 이번 글에서는, await 상황에서 어떻게 동작하는지 좀 더 설명을 해볼 텐데요, 이를 위해 예제 코드에 await 호출을 추가한 다음,

int _callCount = 0;

private async void Window_Loaded(object sender, RoutedEventArgs e)
{
    System.Diagnostics.Trace.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {_callCount} =====Window_Loaded step1=====");
    await Task.Delay(16);
    System.Diagnostics.Trace.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {_callCount} =====Window_Loaded step2=====");
            _callCount++;
}

private void Hooks_OperationPosted(object sender, System.Windows.Threading.DispatcherHookEventArgs e)
{
    string name = GetName(e.Operation);
    Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {name}");
}

실행해 보면 이런 결과가 나옵니다.

...[생략]...
[1] System.Windows.Input.CommandManager.RaiseRequerySuggested
[1] 0 =====Window_Loaded step1=====
[1] System.Windows.Window.<PostContentRendered>b__204_0
[3] System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0
[1] 0 =====Window_Loaded step2=====
[1] System.Windows.Media.MediaContext.RenderMessageHandler
...[생략]...

위의 결과를 해석해 볼까요? ^^ 우선, "await Task.Delay(16)"로 인해 비동기 호출이 되었고, 약 16ms 이후에 스레드풀의 여유 스레드가 callback을 받게 됩니다. 바로 그 스레드가 3번 스레드인 것입니다.

3번 스레드는 await 이후의 코드를 담은 (C# 컴파일러가 IAsyncStateMachine을 상속받아 생성한 타입의) 메서드를 직접 호출하지는 않고, 단순히 Dispatcher에 전달하는 역할만 합니다. 그래서 (await 이후의 코드에 해당하는) "Window_Loaded step2" 코드는 UI 스레드에서 실행되므로 "[1]"번 스레드 값을 출력하는 것입니다.




자, 그럼 이것도 우리가 직접 호출을 해볼까요? 재미있게도, 이번에는 지난번처럼 _method를 가져오면 Action 타입이 아닌, SendOrPostCallback 타입으로 나옵니다.

private void Hooks_OperationPosted(object sender, System.Windows.Threading.DispatcherHookEventArgs e)
{
    string name = GetName(e.Operation);
    Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {name}");

    string target = "System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0";
    if (name == target)
    {
        Console.WriteLine($"============ {e.Operation.Task.Id} ==============");
                
        System.Delegate method = GetMethod(e.Operation);

        if (method is Action action)
        {
            action();
        }
        else if (method is SendOrPostCallback callback)
        {
            callback(null);
        }
    }
}

일단 callback의 인자로 null을 넣었는데요, 실행해 보면 "System.NullReferenceException: 'Object reference not set to an instance of an object.'" 예외가 발생합니다. 오호~~~ 뭔가 전달해야 한다는 건데요, 그래서 디버깅 상태로 DispatcherHookEventArgs를 이거저거 살펴보니 _args 필드가 보이는데, 왠지 이름에서부터 딱 그거라고 하는 듯합니다. ^^

실제로 _args까지 구해서 확인해 보면,

private void Hooks_OperationPosted(object sender, System.Windows.Threading.DispatcherHookEventArgs e)
{
    string name = GetName(e.Operation);
    Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {name}");

    string target = "System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0";
    if (name == target)
    {
        Console.WriteLine($"============ {e.Operation.Task.Id} ==============");
                
        System.Delegate method = GetMethod(e.Operation);
        object objArg = GetArg(e.Operation); // 타입이 Action이고, 실제 await 관련 코드를 담은 메서드가 반환됨

        if (method is Action action)
        {
            action();
        }
        else if (method is SendOrPostCallback callback)
        {
            callback(objArg);
        }
    }
}

static object GetArg(DispatcherOperation dop)
{
    FieldInfo fi = typeof(DispatcherOperation).GetField("_args", BindingFlags.Instance | BindingFlags.NonPublic);
    return fi.GetValue(dop);
}

정상적으로 실행되는 것을 확인할 수 있습니다.




그런데, 출력 결과를 보면 약간 이상한 점이 눈에 띕니다.

...[생략]...
[1] System.Windows.Input.InputManager.ContinueProcessingStagingArea
[1] System.Windows.Input.CommandManager.RaiseRequerySuggested
[1] 0 =====Window_Loaded step1=====
[1] System.Windows.Window.<PostContentRendered>b__204_0
[3] System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0
============ 11 ==============
[3] 0 =====Window_Loaded step2=====
[1] 1 =====Window_Loaded step1=====
[1] System.Windows.Media.MediaContext.RenderMessageHandler
[8] Microsoft.VisualStudio.DesignTools.WpfTap.Utility.DispatcherUtility+<>c__DisplayClass1_0.<SafeInvokeAsync>b__0
[3] System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0
============ 20 ==============
[3] 1 =====Window_Loaded step2=====
...[생략]...

가만 보면, Window_Loaded가 한 번 더 실행되는 것으로 나옵니다.

게다가, 출력된 스레드 ID를 보면, 3번 스레드에서 "Window_Loaded step2"가 실행되는 것까진 이해를 하겠는데, 뒤이어서 1번 스레드가 마치 "Window_Loaded" 함수를 처음부터 실행하는 것처럼 "Window_Loaded step1"부터 다시 보여주고 있습니다.

도대체 왜 이런 결과가 나오는 것일까요? ^^

사실 두 번 실행되는 것은 맞습니다. 우리가 Hooks_OperationPosted 이벤트로부터 해당 함수를 직접 호출했다고 해서 Dispatcher Queue에 들어간 작업이 없어지는 것은 아니므로, 이후 UI 스레드에 의해서 그 작업이 재차 실행되기 때문입니다.

여기서 문제는, 왜 UI 스레드에 의해 실행된 2번째 단계에서 Window_Loaded를 처음부터 다시 시작하냐는 점입니다.

왜냐하면, Hooks_OperationPosted 단계에서 우리가 직접 실행했던 것은 C#이 만든 IAsyncStateMachine은 상탯값을 "this.<>1__state = -2;"로 설정해 버리기 때문입니다. 즉, 3번 스레드에서 실행한 것으로 인해 상태 머신의 상탯값이 "-2"로 바뀌었고, 그 상태 머신을 (UI 스레드가) 다시 실행하는 과정에서 state의 값이 0이 아니므로 또다시 처음 상태를 반복해 실행하는 것입니다.

예측할 수 있듯이, 위와 같이 진행이 되면 1번(UI) 스레드에서 호출된 상태 머신의 반복으로 계속해서 Window_Loaded step1, Window_Loaded step2 쌍을 이루는 출력이 발생합니다. 그러다 어느 순간 운에 따라, UI 스레드가 Hooks_OperationPosted 내의 callback(objArgs) 코드보다 앞서 실행되면,

...[생략]...
[1] System.Windows.Input.CommandManager.RaiseRequerySuggested
[1] 0 =====Window_Loaded step1=====
[1] System.Windows.Window.<PostContentRendered>b__204_0
[3] System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation+<>c.<.cctor>b__8_0
============ 11 ==============
[1] 0 =====Window_Loaded step2===== // UI 스레드가 먼저 실행
[3] 0 =====Window_Loaded step1===== // callback(arg)로 반복 실행, 이후 await Task.Delay(16)가 Non-UI 스레드에서 실행됐으므로,
[1] System.Windows.Media.MediaContext.RenderMessageHandler
[8] Microsoft.VisualStudio.DesignTools.WpfTap.Utility.DispatcherUtility+<>c__DisplayClass1_0.<SafeInvokeAsync>b__0
[3] 1 =====Window_Loaded step2===== // Dispatcher Queue에 추가되지 않고 스레드풀의 스레드에 의해 마저 처리됨
[1] Microsoft.VisualStudio.DesignTools.WpfTap.Utility.DispatcherUtility+<>c__DisplayClass1_0.<SafeInvokeAsync>b__0
...[생략]...

이번에는 비록 UI 스레드에 의해 상태는 "-2"로 바뀌지만 이후 실행되는 callback(objArgs)가 3번 스레드에 의해 실행, 이어서 내부의 await Task.Delay(16) 코드가 UI 스레드에서 실행된 것이 아니므로 (Dispatcher로 전달되지 않으므로) 재귀적으로 반복 호출되는 구문이 끝나게 됩니다. (원칙만 알면, 설명하지 못할 현상이 없습니다. ^^;)

꽤나 설명이 복잡해졌는데요, 그냥 Hooks_OperationPosted의 인자로 넘어온 값을 이용해 우리도 await 이후의 코드를 호출할 수 있었다는 사실만 알고 넘어가도 되겠습니다. ^^

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




참고로, 본문의 코드에서 await 코드를 다음과 같이 바꾸면,

private async void Window_Loaded(object sender, RoutedEventArgs e)
{
    System.Diagnostics.Trace.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}]==========");
    await Task.Delay(16).ConfigureAwait(false); // 이후 코드를 UI 스레드가 아닌 callback을 받은 스레드풀의 스레드에서 실행
    System.Diagnostics.Trace.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}]==========");
    this.textBox1.Text = "Hello World"; // UI 스레드에서 접근하지 않았으므로 예외 발생
}

이런 출력 결과가 나옵니다.

...[생략]...
[1] System.Windows.Input.CommandManager.RaiseRequerySuggested
[1]==========
[1] System.Windows.Window.<PostContentRendered>b__204_0
[3]==========
Exception thrown: 'System.InvalidOperationException' in WindowsBase.dll
[1] System.Windows.Media.MediaContext.RenderMessageHandler
...[생략]...

즉, await 호출 후 16ms 시간이 지나 callback을 받은 스레드풀의 스레드가 Dispatcher로 작업을 넘기지 않고 직접 호출했기 때문에 System.InvalidOperationException 예외가 발생합니다. 다시 말해, ConfigureAwait(false) 호출로 인해 Dispatcher Queue에도 추가되지 않았으므로 당연히 Hooks_OperationPosted 이벤트도 발생하지 않았습니다.




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







[최초 등록일: ]
[최종 수정일: 3/1/2024]

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)
13357정성태5/16/20233576.NET Framework: 2124. C# - Semantic Kernel의 Planner 사용 예제파일 다운로드1
13356정성태5/15/20233902DDK: 10. Device Driver 테스트 설치 관련 오류 (Code 37, Code 31) 및 인증서 관련 정리
13355정성태5/12/20233837.NET Framework: 2123. C# - Semantic Kernel의 ChatGPT 대화 구현 [1]파일 다운로드1
13354정성태5/12/20234096.NET Framework: 2122. C# - "Use Unicode UTF-8 for worldwide language support" 설정을 한 경우, 한글 입력이 '\0' 문자로 처리
13352정성태5/12/20233706.NET Framework: 2121. C# - Semantic Kernel의 대화 문맥 유지파일 다운로드1
13351정성태5/11/20234211VS.NET IDE: 185. Visual Studio - 원격 Docker container 내에 실행 중인 응용 프로그램에 대한 디버깅 [1]
13350정성태5/11/20233481오류 유형: 859. Windows Date and Time - Unable to continue. You do not have permission to perform this task
13349정성태5/11/20233793.NET Framework: 2120. C# - Semantic Kernel의 Skill과 Function 사용 예제파일 다운로드1
13348정성태5/10/20233690.NET Framework: 2119. C# - Semantic Kernel의 "Basic Loading of the Kernel" 예제
13347정성태5/10/20234083.NET Framework: 2118. C# - Semantic Kernel의 Prompt chaining 예제파일 다운로드1
13346정성태5/10/20233914오류 유형: 858. RDP 원격 환경과 로컬 PC 간의 Ctrl+C, Ctrl+V 복사가 안 되는 문제
13345정성태5/9/20235314.NET Framework: 2117. C# - (OpenAI 기반의) Microsoft Semantic Kernel을 이용한 자연어 처리 [1]파일 다운로드1
13344정성태5/9/20236493.NET Framework: 2116. C# - OpenAI API 사용 - 지원 모델 목록 [1]파일 다운로드1
13343정성태5/9/20234366디버깅 기술: 192. Windbg - Hyper-V VM으로 이더넷 원격 디버깅 연결하는 방법
13342정성태5/8/20234274.NET Framework: 2115. System.Text.Json의 역직렬화 시 필드/속성 주의
13341정성태5/8/20234007닷넷: 2114. C# 12 - 모든 형식의 별칭(Using aliases for any type)
13340정성태5/8/20234080오류 유형: 857. Microsoft.Data.SqlClient.SqlException - 0x80131904
13339정성태5/6/20234747닷넷: 2113. C# 12 - 기본 생성자(Primary Constructors)
13338정성태5/6/20234265닷넷: 2112. C# 12 - 기본 람다 매개 변수파일 다운로드1
13337정성태5/5/20234770Linux: 59. dockerfile - docker exec로 container에 접속 시 자동으로 실행되는 코드 적용
13336정성태5/4/20234579.NET Framework: 2111. C# - 바이너리 출력 디렉터리와 연관된 csproj 설정
13335정성태4/30/20234680.NET Framework: 2110. C# - FFmpeg.AutoGen 라이브러리를 이용한 기본 프로젝트 구성 - Windows Forms파일 다운로드1
13334정성태4/29/20234313Windows: 250. Win32 C/C++ - Modal 메시지 루프 내에서 SetWindowsHookEx를 이용한 Thread 메시지 처리 방법
13333정성태4/28/20233755Windows: 249. Win32 C/C++ - 대화창 템플릿을 런타임에 코딩해서 사용파일 다운로드1
13332정성태4/27/20233856Windows: 248. Win32 C/C++ - 대화창을 위한 메시지 루프 사용자 정의파일 다운로드1
13331정성태4/27/20233887오류 유형: 856. dockerfile - 구 버전의 .NET Core 이미지 사용 시 apt update 오류
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...