Microsoft MVP성태의 닷넷 이야기
.NET Framework: 916. C# - Task.Yield 사용법 (2) [링크 복사], [링크+제목 복사],
조회: 18798
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 4개 있습니다.)
.NET Framework: 914. C# - Task.Yield 사용법
; https://www.sysnet.pe.kr/2/0/12241

.NET Framework: 916. C# - Task.Yield 사용법 (2)
; https://www.sysnet.pe.kr/2/0/12245

.NET Framework: 1163.  C# - 윈도우 환경에서 usleep을 호출하는 방법
; https://www.sysnet.pe.kr/2/0/12980

.NET Framework: 1195. C# - Thread.Yield와 Thread.Sleep(0)의 차이점(?)
; https://www.sysnet.pe.kr/2/0/13033




C# - Task.Yield 사용법 (2)

네이버에 다음의 질문이 올라왔습니다.

https://blog.naver.com/PostView.nhn?blogId=techshare&logNo=222010099913

질문을 정리해 보면, 제시한 코드의 상황에서,

private async Task DoDialogAsync()
{
    var dialog = new Form();

    Func<Task> showAsync = async () =>
    {
        Output("Before Task.Yield() in showAsync");
        await Task.Yield();

        Output("After Task.Yield() in showAsync");
        dialog.ShowDialog();
        Output("Dialog Shown");
    };

    var dialogTask = showAsync();

    Output("111111");

    MessageBox.Show("The dialog is visible, click OK to close");

    Output("MessageBox Shown");
    dialog.Close();
    Output("Dialog Closed");

    await dialogTask;
}

void Output(string txt)
{
    Trace.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {txt}");
}

다음과 같은 순서로 출력이 나오는 이유를 모르겠다는 것입니다.

[1] Before Task.Yield() in showAsync
[1] 111111
[1] After Task.Yield() in showAsync
-- ShowDialog 대화창 뜨고,
[1] Dialog Shown
-- MessageBox.Show 뜨고,
[1] MessageBox Shown
[1] Dialog Closed




만약 여기서 await Task.Yield() 호출을 빼면 출력은 다음과 같이 바뀝니다.

[1] Before Task.Yield() in showAsync
[1] After Task.Yield() in showAsync
-- ShowDialog 대화창 뜨고,
[1] Dialog Shown
[1] 111111
-- MessageBox.Show 뜨고,
[1] MessageBox Shown
[1] Dialog Closed

그 차이점은, 지난 글에서도 밝혔듯이 Task.Yield의 처리가 다음의 코드와 동일하기 때문에,

var tcs = new TaskCompletionSource<bool>();
var sc = SynchronizationContext.Current;
if (sc != null)
    sc.Post(_ => tcs.SetResult(true), null);
else
    ThreadPool.QueueUserWorkItem(_ => tcs.SetResult(true));
await tcs.Task;

질문자가 제시한 코드를 이렇게 바꿔도 상관없습니다.

private async Task DoDialogAsync()
{
    var dialog = new Form();

    Func<Task> showAsync = async () =>
    {
        Output("Before Task.Yield() in showAsync");
        
        var tcs = new TaskCompletionSource<bool>();
        var sc = SynchronizationContext.Current;
        if (sc != null)
            sc.Post(_ => tcs.SetResult(true), null);
        else
            ThreadPool.QueueUserWorkItem(_ => tcs.SetResult(true));
        await tcs.Task;

        Output("After Task.Yield() in showAsync");
        dialog.ShowDialog();
        Output("Dialog Shown");
    };

    var dialogTask = showAsync();

    Output("await Task.Yield()");
    Output("111111");

    MessageBox.Show("The dialog is visible, click OK to close");

    Output("MessageBox Shown");
    dialog.Close();
    Output("Dialog Closed");

    await dialogTask;
}

위의 코드를 보면, 익명 비동기 함수(showAsync) 내에서 "await tcs.Task" 이후의 코드가 언제 실행이 될지 예측할 수 있는데, 바로 "tcs.SetResult"가 실행이 되어야만 합니다. 그리고 그것은 SynchronizationContext.Current에 의해 Post로 전달되었으므로, 즉 UI 스레드가 Win32 메시지 루프 처리를 할 수 있을 때 이뤄집니다.

이로 인해, showAsync() 후 MessageBox.Show를 호출하는 시점에 그 내부에서 (메시지 박스가 뜨기 전) 메시지 루프 처리에 진입하면 tcs.SetResult가 실행되고, 그로 인해 "await tcs.Task" 이후의 코드 조각이 UI 스레드에서 이어서 실행이 됩니다. MessageBox.Show가 실행된 시점에 dialog.ShowDialog가 먼저 실행되는 것은 바로 이런 처리 순서 때문에 발생하는 것입니다.

일단, 이걸로 처리 순서가 달라지는 이유는 설명되었을 것 같고.




제가 저번 글에서 Task.Yield가 SynchronizationContext 환경하에서는 호출 유무에 영향을 받지 않는다고 했는데, 위의 내용으로 보면 분명히 실행에 영향을 주고 있습니다.

그리고 이해가 복잡할 정도로 코드의 실행이 난해해졌는데요. 사실 이것은 질문하신 분이 async/await을 복잡하게 사용했기 때문입니다. 일례로, showAsync 호출을 원래는 다음과 같이 했어야 합니다.

private async Task DoDialogAsync()
{
    var dialog = new Form();

    Func<Task> showAsync = async () =>
    {
        Output("Before Task.Yield() in showAsync");
                
        await Task.Yield();

        Output("After Task.Yield() in showAsync");
        dialog.ShowDialog();
        Output("Dialog Shown");
    };

    await showAsync();

    Output("111111");

    MessageBox.Show("The dialog is visible, click OK to close");

    Output("MessageBox Shown");
    dialog.Close();
    Output("Dialog Closed");
}

그럼 다음과 같이 출력 순서가 (예측이 가능한 정도로 깔끔하게 정리가) 되고,

[1] Before Task.Yield() in showAsync
[1] After Task.Yield() in showAsync
-- ShowDialog 대화창 뜨고,
[1] Dialog Shown
[1] 111111
-- MessageBox.Show 뜨고,
[1] MessageBox Shown
[1] Dialog Closed

이것은 위에서 질문자가 제시했던 코드에서 "await Task.Yield()"를 뺐을 때의 경우와 완전히 일치합니다. 게다가 async 메서드를 제거해서 inline으로 코드로 작성했을 때와도,

private async Task DoDialogAsync()
{
    var dialog = new Form();

    Output("Before Task.Yield() in showAsync");
    await Task.Yield();
    Output("After Task.Yield() in showAsync");
    dialog.ShowDialog();
    Output("Dialog Shown");

    Output("111111");

    MessageBox.Show("The dialog is visible, click OK to close");

    Output("MessageBox Shown");
    dialog.Close();
    Output("Dialog Closed");
}

동일한 출력을 가집니다. 즉, await 호출을 하지 않고 직접 Task를 반환받는 코드를 사용해 다른 코드와 섞어 실행하는 방식으로 처리했기 때문에 원래의 코드에서 순서가 예측할 수 없을 정도로 어려웠던 것입니다. 따라서 꼭 Task.Yield를 써서 그랬던 것은 아니고, 다른 Task.Factory.StartNew나 스레드 등의 처리를 했어도 마찬가지였을 것입니다.

예를 들어, 원래 이런 식으로 비동기 호출을 하던 것을,

private async void Button_Click(object sender, RoutedEventArgs e)
{
    byte[] data = ...
    await myDevice.WriteAsync(data, 0, data.Length);
    // ... 사용자 코드 ...  
}

굳이 어렵게 다음과 같이 함으로써,

private async void Button_Click(object sender, RoutedEventArgs e)
{
    byte[] data = ...
    Task<bool> task = myDevice.WriteAsync(data, 0, data.Length);
    // ... 사용자 코드 ...  
    await task;
}

"... 사용자 코드 ..." 영역이 WriteAsync 내의 메서드 실행이 모두 끝나기도 전에 실행이 될 수 있으므로 WriteAsync 내의 구현 코드를 고려해 어떻게 실행 순서가 될지 심각하게 고민하는 것과 다를 바가 없습니다.




첨언을 또 해 보면, 제가 저번 글에서 Task.Yield가 SynchronizationContext 환경하에서는 의미가 없다고도 했습니다. 제가 위의 예제 코드에서 Output 메서드에 Thread.CurrentThread.ManagedThreadId를 함께 출력하도록 했는데요.

모든 코드가 1번, 즉 UI 스레드에서 실행되고 있는 것을 볼 수 있습니다.

[1] Before Task.Yield() in showAsync
[1] 111111
[1] After Task.Yield() in showAsync
-- ShowDialog 대화창 뜨고,
[1] Dialog Shown
-- MessageBox.Show 뜨고,
[1] MessageBox Shown
[1] Dialog Closed

따라서 SynchronizationContext의 영향이 있는 경우, Task.Yield는 써도 그만, 안 써도 그만인 코드가 된 것입니다.

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 6/25/2020]

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

비밀번호

댓글 작성자
 



2020-06-30 01시22분
[이성환] 좋은 글 감사합니다.
개인적인 생각으로는 비동기 코루틴을 만들기 위한 용도 이외에는 그다지 큰 쓸모가 있지는 않을 듯 합니다. 동기화 처리를 하면서 비동기 코루틴이 필요하다면 await Task.Yield() 가 나름 괜찮은 방법 같아보이지만...
저같은 개발자가 현실에서 쓸 일은 드물어보이네요. -ㅁ-;;
[guest]
2020-07-01 07시26분
@이성환 그러게요. 저도 이에 대해 설명은 했지만, 딱히 일반 업무에서의 사용처를 찾기가 쉽지 않군요. ^^
정성태

1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13718정성태8/27/20247448오류 유형: 921. Visual C++ - error C1083: Cannot open include file: 'float.h': No such file or directory [2]
13717정성태8/26/20247037VS.NET IDE: 192. Visual Studio 2022 - Windows XP / 2003용 C/C++ 프로젝트 빌드
13716정성태8/21/20246768C/C++: 167. Visual C++ - 윈도우 환경에서 _execv 동작 [1]
13715정성태8/19/20247386Linux: 78. 리눅스 C/C++ - 특정 버전의 glibc 빌드 (docker-glibc-builder)
13714정성태8/19/20246769닷넷: 2295. C# 12 - 기본 생성자(Primary constructors) (책 오타 수정) [3]
13713정성태8/16/20247497개발 환경 구성: 721. WSL 2에서의 Hyper-V Socket 연동
13712정성태8/14/20247231개발 환경 구성: 720. Synology NAS - docker 원격 제어를 위한 TCP 바인딩 추가
13711정성태8/13/20248077Linux: 77. C# / Linux - zombie process (defunct process) [1]파일 다운로드1
13710정성태8/8/20248009닷넷: 2294. C# 13 - (6) iterator 또는 비동기 메서드에서 ref와 unsafe 사용을 부분적으로 허용파일 다운로드1
13709정성태8/7/20247767닷넷: 2293. C# - safe/unsafe 문맥에 대한 C# 13의 (하위 호환을 깨는) 변화파일 다운로드1
13708정성태8/7/20247559개발 환경 구성: 719. ffmpeg / YoutubeExplode - mp4 동영상 파일로부터 Audio 파일 추출
13707정성태8/6/20247793닷넷: 2292. C# - 자식 프로세스의 출력이 4,096보다 많은 경우 Process.WaitForExit 호출 시 hang 현상파일 다운로드1
13706정성태8/5/20247910개발 환경 구성: 718. Hyper-V - 리눅스 VM에 새로운 디스크 추가
13705정성태8/4/20248170닷넷: 2291. C# 13 - (5) params 인자 타입으로 컬렉션 허용 [2]파일 다운로드1
13704정성태8/2/20248127닷넷: 2290. C# - 간이 dotnet-dump 프로그램 만들기파일 다운로드1
13703정성태8/1/20247454닷넷: 2289. "dotnet-dump ps" 명령어가 닷넷 프로세스를 찾는 방법
13702정성태7/31/20247867닷넷: 2288. Collection 식을 지원하는 사용자 정의 타입을 CollectionBuilder 특성으로 성능 보완파일 다운로드1
13701정성태7/30/20248139닷넷: 2287. C# 13 - (4) Indexer를 이용한 개체 초기화 구문에서 System.Index 연산자 허용파일 다운로드1
13700정성태7/29/20247759디버깅 기술: 200. DLL Export/Import의 Hint 의미
13699정성태7/27/20248252닷넷: 2286. C# 13 - (3) Monitor를 대체할 Lock 타입파일 다운로드1
13698정성태7/27/20248217닷넷: 2285. C# - async 메서드에서의 System.Threading.Lock 잠금 처리파일 다운로드1
13697정성태7/26/20247934닷넷: 2284. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리파일 다운로드1
13696정성태7/26/20247469오류 유형: 920. dotnet publish - error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for '...'
13695정성태7/25/20247457닷넷: 2283. C# - Lock / Wait 상태에서도 STA COM 메서드 호출 처리파일 다운로드1
13694정성태7/25/20247920닷넷: 2282. C# - ASP.NET Core Web App의 Request 용량 상한값 (Kestrel, IIS)
13693정성태7/24/20247245개발 환경 구성: 717. Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법파일 다운로드1
1  2  3  4  5  6  7  8  [9]  10  11  12  13  14  15  ...