Microsoft MVP성태의 닷넷 이야기
닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인 [링크 복사], [링크+제목 복사],
조회: 1822
글쓴 사람
정성태 (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)
12257정성태7/7/20209381.NET Framework: 925. C# - ETW를 이용한 Monitor Enter/Exit 감시파일 다운로드1
12256정성태7/7/20209801.NET Framework: 924. C# - Reflection으로 변경할 수 없는 readonly 정적 필드 [4]
12255정성태7/6/202010232.NET Framework: 923. C# - ETW(Event Tracing for Windows)를 이용한 Finalizer 실행 감시파일 다운로드1
12254정성태7/2/202010070오류 유형: 626. git - REMOTE HOST IDENTIFICATION HAS CHANGED!
12253정성태7/2/202011135.NET Framework: 922. C# - .NET ThreadPool의 Local/Global Queue파일 다운로드1
12252정성태7/2/202013133.NET Framework: 921. C# - I/O 스레드를 사용한 비동기 소켓 서버/클라이언트파일 다운로드2
12251정성태7/1/202011084.NET Framework: 920. C# - 파일의 비동기 처리 유무에 따른 스레드 상황 [1]파일 다운로드2
12250정성태6/30/202013708.NET Framework: 919. C# - 닷넷에서의 진정한 비동기 호출을 가능케 하는 I/O 스레드 사용법 [1]파일 다운로드1
12249정성태6/29/20209839오류 유형: 625. Microsoft SQL Server 2019 RC1 Setup - 설치 제거 시 Warning 26003 오류 발생
12248정성태6/29/20208240오류 유형: 624. SQL 서버 오류 - service-specific error code 17051
12247정성태6/29/20209815.NET Framework: 918. C# - 불린 형 상수를 반환값으로 포함하는 3항 연산자 사용 시 단축 표현 권장(IDE0075) [2]파일 다운로드1
12246정성태6/29/202010631.NET Framework: 917. C# - USB 관련 ETW(Event Tracing for Windows)를 이용한 키보드 입력을 감지하는 방법
12245정성태6/24/202011109.NET Framework: 916. C# - Task.Yield 사용법 (2) [2]파일 다운로드1
12244정성태6/24/202010950.NET Framework: 915. ETW(Event Tracing for Windows)를 이용한 닷넷 프로그램의 내부 이벤트 활용 [1]파일 다운로드1
12243정성태6/23/20208513VS.NET IDE: 147. Visual C++ 프로젝트 - .NET Core EXE를 "Debugger Type"으로 지원하는 기능 추가
12242정성태6/23/20209263오류 유형: 623. AADSTS90072 - User account '...' from identity provider 'live.com' does not exist in tenant 'Microsoft Services'
12241정성태6/23/202012586.NET Framework: 914. C# - Task.Yield 사용법파일 다운로드1
12240정성태6/23/202013867오류 유형: 622. 소켓 바인딩 시 "System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions" 오류 발생
12239정성태6/21/202010334Linux: 30. (윈도우라면 DLL에 속하는) .so 파일이 텍스트로 구성된 사례 [1]
12238정성태6/21/202010230.NET Framework: 913. C# - SharpDX + DXGI를 이용한 윈도우 화면 캡처 라이브러리
12237정성태6/20/20209995.NET Framework: 912. 리눅스 환경의 .NET Core에서 "test".IndexOf("\0")가 0을 반환
12236정성태6/19/202010381오류 유형: 621. .NET Standard 대상으로 빌드 시 dynamic 예약어에서 컴파일 오류 - error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'
12235정성태6/19/20209991오류 유형: 620. Windows 10 - Inaccessible boot device 블루 스크린
12234정성태6/19/20209722개발 환경 구성: 494. NuGet - nuspec의 패키지 스키마 버전(네임스페이스) 업데이트 방법
12233정성태6/19/20209431오류 유형: 619. SQL 서버 - The transaction log for database '...' is full due to 'LOG_BACKUP'. - 두 번째 이야기
12232정성태6/19/20208395오류 유형: 618. SharePoint - StoreBusyRetryLater 오류
... 46  47  48  49  50  51  52  53  54  [55]  56  57  58  59  60  ...