Microsoft MVP성태의 닷넷 이야기
닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인 [링크 복사], [링크+제목 복사],
조회: 1778
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...
NoWriterDateCnt.TitleFile(s)
12154정성태2/25/20208702오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202011385.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202011144.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202011686.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011547.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011322.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012544디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202011174디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202011410.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202010632.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/13/202010625.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/20208702.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/12/202010453.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/202010025.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [2]파일 다운로드1
12140정성태2/10/20209888.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/202011262.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/202014030.NET Framework: 885. C# - 닷넷 응용 프로그램에서 SQLite 사용 [6]파일 다운로드1
12137정성태2/9/20209230오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/20209622Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태2/6/202013251개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [2]
12134정성태2/5/202013406.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [5]파일 다운로드1
12133정성태2/5/202010656디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태1/28/202012221.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/202012268개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법 [1]
12130정성태1/26/20209743VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202015310.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...