Microsoft MVP성태의 닷넷 이야기
.NET Framework: 719. Task를 포함하는 async 메서드의 동작 방식 [링크 복사], [링크+제목 복사],
조회: 21892
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 12개 있습니다.)
.NET Framework: 698. C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드
; https://www.sysnet.pe.kr/2/0/11351

.NET Framework: 716. async 메서드의 void 반환 타입 사용에 대하여
; https://www.sysnet.pe.kr/2/0/11414

.NET Framework: 717. Task를 포함하지 않는 async 메서드의 동작 방식
; https://www.sysnet.pe.kr/2/0/11415

.NET Framework: 719. Task를 포함하는 async 메서드의 동작 방식
; https://www.sysnet.pe.kr/2/0/11417

.NET Framework: 731. C# - await을 Task 타입이 아닌 사용자 정의 타입에 적용하는 방법
; https://www.sysnet.pe.kr/2/0/11456

.NET Framework: 737. C# - async를 Task 타입이 아닌 사용자 정의 타입에 적용하는 방법
; https://www.sysnet.pe.kr/2/0/11484

.NET Framework: 813. C# async 메서드에서 out/ref/in 유형의 인자를 사용하지 못하는 이유
; https://www.sysnet.pe.kr/2/0/11850

닷넷: 2138. C# - async 메서드 호출 원칙
; https://www.sysnet.pe.kr/2/0/13405

닷넷: 2147. C# - 비동기 메서드의 async 예약어 유무에 따른 차이
; https://www.sysnet.pe.kr/2/0/13421

닷넷: 2318. C# - (async Task가 아닌) async void 사용 시의 부작용
; https://www.sysnet.pe.kr/2/0/13884

닷넷: 2319. ASP.NET Core Web API / Razor 페이지에서 발생할 수 있는 async void 메서드의 부작용
; https://www.sysnet.pe.kr/2/0/13885

닷넷: 2321. Blazor에서 발생할 수 있는 async void 메서드의 부작용
; https://www.sysnet.pe.kr/2/0/13888




Task를 포함하는 async 메서드의 동작 방식

이전 글에 이어서,

Task를 포함하지 않는 async 메서드의 동작 방식
; https://www.sysnet.pe.kr/2/0/11415

이번에는 예제 코드를 Task가 있는 것으로 넣어 흐름을 살펴보겠습니다. 이를 위해 예제 코드는 다음의 글에서 작성했던 것으로 재활용합니다.

C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드
; https://www.sysnet.pe.kr/2/0/11351

using System;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    class Program
    {
        // C# 7.1 async Main
        static async Task Main(string[] args)
        {
            Program pg = new Program();

            await pg.CallAsync();
        }

        private async Task CallAsync()
        {
            string title = DateTime.Now.ToString();
            string text = await GetFileContents();
            Console.WriteLine(title + ": " + text);
        }

        private async Task<string> GetFileContents()
        {
            return await new TaskFactory().StartNew(() => { Thread.Sleep(5000); return "test"; });
        }
    }
}

위의 코드에서 GetFileContents는 async 예약어로 인해 다음과 같은 식으로 코드 구성을 합니다.

private Task<string> GetFileContents()
{
    GetFileContents_StateMachine stateMachine = new GetFileContents_StateMachine
    {
        _this = this,
        _builder = AsyncTaskMethodBuilder<string>.Create(),
        _state = -1,
    };

    stateMachine._builder.Start(ref stateMachine);
    return stateMachine._builder.Task as Task<string>;
}

그리고 stateMachine._builder.Start 호출로 인해 상태 머신의 MoveNext에서 실행되는 첫 코드는 다음과 같습니다.

this._getStringTask = new TaskFactory().StartNew(() => { Thread.Sleep(5000); return "test"; });
awaiter = this._getStringTask.GetAwaiter();
if (awaiter.IsCompleted == false)
{
    this._state = num = 0;
    this._awaiter = awaiter;
    GetFileContents_StateMachine stateMachine = this;
    this._builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);
    return;
}

사실 이번 글을 쓰기 전까지는, 저 위의 this._getStringTask가 GetFileContents의 마지막에 반환하는 stateMachine._builder.Task일 거라고 생각했었습니다. 그런데, 실제로 해보면 저 2개의 Task는 같지 않습니다.

다시 말해, stateMachine._builder.Task는 GetFileContents 메서드가 async로 바뀌는 바람에 내부에 생성되었던 상태 머신의 AsyncTaskMethodBuilder<string>.Create()로 생성되었던 Task인 반면, this._getStringTask는 그냥 await 예약어의 대상이 되는 메서드가 반환한 Task를 그대로 유지합니다.

동일한 규칙이 GetFileContents를 호출하는 CallAsync에도 적용됩니다. CallAsync는 다음과 같이 상태 머신을 생성하는 코드로 바뀌고,

private Task CallAsync()
{
    CallAsync_StateMachine stateMachine = new CallAsync_StateMachine
    {
        _this = this,
        _builder = AsyncTaskMethodBuilder.Create(),
        _state = -1,
    };

    stateMachine._builder.Start(ref stateMachine);
    return stateMachine._builder.Task;
}

CallAsync 상태 머신의 첫 번째 MoveNext 실행 코드는,

awaiter = _this.GetFileContents().GetAwaiter();
if (awaiter.IsCompleted == false)
{
    this._state = num = 0;
    this._awaiter = awaiter;
    CallAsync_StateMachine stateMachine = this;
    this._builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);
    return;
}

GetFileContents() 내에서 TaskFactory().StartNew()로 생성되었던 Task가 아닌, GetFileContents 스스로 생성한 Task 객체의 Awaiter를 받아 비동기를 연결합니다.

정리해 보면, 다음과 같은 식으로 Task 객체가 연결됩니다.

GetFileContents
    task = TaskFactory().StartNew() 코드 실행
    task가 동작이 끝나면 실행될 MoveNext 코드를 등록
    
    하지만 스스로 상태 머신에서 AsyncTaskMethodBuilder<string>.Create()로 생성한 Task를 반환

CallAsync
    GetFileContents가 스스로 생성한 Task를 구하고,
    그 Task의 동작이 끝나면 실행될 MoveNext 코드를 등록    

    하지만 스스로 상태 머신에서 AsyncTaskMethodBuilder.Create()로 생성한 Task를 반환

즉, 스레드를 소유한 Task가 호출 스택을 타고 전달되는 것이 아니라, 각각의 async 메서드마다 스스로 생성한 Task 객체를 상위에 전달하고 있었던 것인데... 보면서 어떻게 이것이 비동기 동작을 하는지 이해가 안 되었습니다.




물론 결과적으로 어쨌든 연결된다는 사실이 중요한데 세부적인 것을 알아보면 대충 이렇습니다.

async 메서드는 그것이 호출한 async 메서드로부터 구한 awaiter의 작업이 끝나지 않은 경우 다음번 작업을 다음과 같이 등록합니다.

awaiter = this.YourAsyncMethod().GetAwaiter();
if (awaiter.IsCompleted == false)
{
    this._state = num = 0;
    this._awaiter = awaiter;
    GetFileContents_StateMachine stateMachine = this;
    this._builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);
    return;
}

AwaitUnsafeOnCompleted는 호출한 async 메서드로부터 반환받은 awaiter와 현재 async 메서드의 상태 머신 객체를 인자로 받습니다. 이를 이용해,

[SecuritySafeCritical, __DynamicallyInvokable]
public void AwaitUnsafeOnCompleted<TAwaiter, TStateMachine>(ref TAwaiter awaiter, ref TStateMachine stateMachine) where TAwaiter: ICriticalNotifyCompletion where TStateMachine: IAsyncStateMachine
{
    try
    {
        AsyncMethodBuilderCore.MoveNextRunner runnerToInitialize = null;
        Action completionAction = this.m_coreState.GetCompletionAction(AsyncCausalityTracer.LoggingOn ? this.Task : null, ref runnerToInitialize);
        if (this.m_coreState.m_stateMachine == null)
        {
            Task<TResult> builtTask = this.Task;
            this.m_coreState.PostBoxInitialization((TStateMachine) stateMachine, runnerToInitialize, builtTask);
        }
        awaiter.UnsafeOnCompleted(completionAction);
    }
    catch (Exception exception)
    {
        AsyncMethodBuilderCore.ThrowAsync(exception, null);
    }
}

AsyncTaskMethodBuilder의 (struct로 함께 생성되었던) m_coreState 객체가 소유한 델리게이트에 StateMachine의 MoveNext 작업을 담은 후 이것을 awaiter의 Task에 연결합니다.

// System.Runtime.CompilerServices.TaskAwaiter

[SecurityCritical, __DynamicallyInvokable]
public void UnsafeOnCompleted(Action continuation)
{
    OnCompletedInternal(this.m_task, continuation, true, false);
}

[MethodImpl(MethodImplOptions.NoInlining), SecurityCritical]
internal static void OnCompletedInternal(Task task, Action continuation, bool continueOnCapturedContext, bool flowExecutionContext)
{
    if (continuation == null)
    {
        throw new ArgumentNullException("continuation");
    }
    StackCrawlMark lookForMyCaller = StackCrawlMark.LookForMyCaller;
    if (TplEtwProvider.Log.IsEnabled() || Task.s_asyncDebuggingEnabled)
    {
        continuation = OutputWaitEtwEvents(task, continuation);
    }
    task.SetContinuationForAwait(continuation, continueOnCapturedContext, flowExecutionContext, ref lookForMyCaller);
}

그리고 Task에 등록된 델리게이트의 수행은 상태 머신의 MoveNext에서 마지막 SetResult(또는 SetException)을 수행할 때 실행됩니다.




정리해 보면, 전체적으로는 다음과 같은 내부적인 비동기 처리가 연쇄적으로 발생합니다.

[async/await 코드 실행 시]

GetFileContents
    Task task = TaskFactory().StartNew 수행
    if (task 수행 완료)
    {
        GetFileContents의 두 번째 MoveNext가 실행될 때의 코드를 동기로 실행
        GetFileContents.Task 역시 수행 완료로 표시
    }
    else
    {
        task에 GetFileContents의 MoveNext를 등록
    }
    GetFileContents.Task 반환

CallAsync
    Task task = GetFileContents가 생성한 Task
    if (task 수행 완료)
    {
        CallAsync의 두 번째 MoveNext가 실행될 때의 코드를 동기로 실행
        CallAsync.Task 역시 수행 완료로 표시
    }
    else
    {
        task에 CallAsync의 MoveNext를 등록
    }
    CallAsync.Task 반환

[StartNew 수행이 완료된 후]
    StartNew Task의 스레드에서 GetFileContents가 등록한 MoveNext를 수행
        GetFileContents.MoveNext 내에서 SetResult 수행
            SetResult 내에서 GetFileContents.Task에 CallAsync가 등록한 MoveNext를 수행
                CallAsync.MoveNext 내에서 SetResult 수행
                    ...[반복]...




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/14/2023]

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

비밀번호

댓글 작성자
 



2023-09-13 09시35분
선생님 혹시 아래 메서드 리턴 타입을
Task에서 Task<string>으로 수정하는 게 맞을까요?
private Task GetFileContents()
{
    GetFileContents_StateMachine stateMachine = new GetFileContents_StateMachine
    {
        _this = this,
        _builder = AsyncTaskMethodBuilder<string>.Create(),
        _state = -1,
    };

    stateMachine._builder.Start(ref stateMachine);
    return stateMachine._builder.Task as Task<string>;
}
한예지
2023-09-14 08시22분
@한예지 언급하신 그 문제도 지난번과 같이 ^^; Task<string>에 대해 HTML escape 처리를 안 해서 그렇게 나온 것입니다. (본문 수정했습니다.)
정성태

... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12289정성태8/6/202017050개발 환경 구성: 502. Portainer에 윈도우 컨테이너를 등록하는 방법
12288정성태8/5/202016024오류 유형: 637. WCF - The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.
12287정성태8/5/202017629오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/202018998개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/202018572오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202017962디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202018917디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/202016669디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202020283개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202018404오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202020221개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/202016790VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202018737개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202018196.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202020302개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202019670개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202022416개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/202015581.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202018545.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202019243오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/202016508오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202019067오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202021247.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202018119오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/202017025오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202028339오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...