Microsoft MVP성태의 닷넷 이야기
닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인 [링크 복사], [링크+제목 복사],
조회: 9428
글쓴 사람
정성태 (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)
13768정성태10/15/20245371C/C++: 179. C++ - _O_WTEXT, _O_U16TEXT, _O_U8TEXT의 Unicode stream 모드파일 다운로드2
13767정성태10/14/20244758오류 유형: 929. bpftrace 수행 시 "ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger"
13766정성태10/14/20244539C/C++: 178. C++ - 파일에 대한 Text 모드의 "translated" 동작파일 다운로드1
13765정성태10/12/20245246오류 유형: 928. go build 시 "package maps is not in GOROOT" 오류
13764정성태10/11/20245612Linux: 85. Ubuntu - 원하는 golang 버전 설치
13763정성태10/11/20244971Linux: 84. WSL / Ubuntu 20.04 - bpftool 설치
13762정성태10/11/20244994Linux: 83. WSL / Ubuntu 22.04 - bpftool 설치
13761정성태10/11/20244903오류 유형: 927. WSL / Ubuntu - /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
13760정성태10/11/20245437Linux: 82. Ubuntu - clang 최신(stable) 버전 설치
13759정성태10/10/20246350C/C++: 177. C++ - 자유 함수(free function) 및 주소 지정 가능한 함수(addressable function) [6]
13758정성태10/8/20245563오류 유형: 926. dotnet tools를 sudo로 실행하는 경우 command not found
13757정성태10/8/20245498닷넷: 2306. Linux - dotnet tool의 설치 디렉터리가 PATH 환경변수에 자동 등록이 되는 이유
13756정성태10/8/20245608오류 유형: 925. ssh로 docker 접근을 할 때 "... malformed HTTP status code ..." 오류 발생
13755정성태10/7/20245997닷넷: 2305. C# 13 - (9) 메서드 바인딩의 우선순위를 지정하는 OverloadResolutionPriority 특성 도입 (Overload resolution priority)파일 다운로드1
13754정성태10/4/20245561닷넷: 2304. C# 13 - (8) 부분 메서드 정의를 속성 및 인덱서에도 확대파일 다운로드1
13753정성태10/4/20245577Linux: 81. Linux - PATH 환경변수의 적용 규칙
13752정성태10/2/20246256닷넷: 2303. C# 13 - (7) ref struct의 interface 상속 및 제네릭 제약으로 사용 가능 [6]파일 다운로드1
13751정성태10/2/20245387C/C++: 176. C/C++ - ARM64로 포팅할 때 유의할 점
13750정성태10/1/20245280C/C++: 175. C++ - WinMain/wWinMain 호출 전의 CRT 초기화 단계
13749정성태9/30/20245520닷넷: 2302. C# - ssh-keygen으로 생성한 Private Key와 Public Key 연동파일 다운로드1
13748정성태9/29/20245730닷넷: 2301. C# - BigInteger 타입이 byte 배열로 직렬화하는 방식
13747정성태9/28/20245569닷넷: 2300. C# - OpenSSH의 공개키 파일에 대한 "BEGIN OPENSSH PUBLIC KEY" / "END OPENSSH PUBLIC KEY" PEM 포맷파일 다운로드1
13746정성태9/28/20245672오류 유형: 924. Python - LocalProtocolError("Illegal header value ...")
13745정성태9/28/20245535Linux: 80. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (lldb)
13744정성태9/27/20245962닷넷: 2299. C# - Windows Hello 사용자 인증 다이얼로그 표시하기파일 다운로드1
13743정성태9/26/20246411닷넷: 2298. C# - Console 프로젝트에서의 await 대상으로 Main 스레드 활용하는 방법 [1]
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...