Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 3개 있습니다.)
(시리즈 글이 3개 있습니다.)
.NET Framework: 725. C# - 동기 방식이면서 비동기 메서드(awaitable)처럼 구현한 사례
; https://www.sysnet.pe.kr/2/0/11431

.NET Framework: 1077. C# - 동기 방식이면서 비동기 규약을 따르게 만드는 Task.FromResult
; https://www.sysnet.pe.kr/2/0/12713

.NET Framework: 2056. C# - await 비동기 호출을 기대한 메서드가 동기로 호출되었을 때의 부작용
; https://www.sysnet.pe.kr/2/0/13138




C# - await 비동기 호출을 기대한 메서드가 동기로 호출되었을 때의 부작용

재미있는 질문이 하나 있습니다.

c# socket.poll 버그인가요?
; https://www.sysnet.pe.kr/3/0/5731

[예제 재현 코드]
; https://www.sysnet.pe.kr/3/0/5732

처음 저 질문을 봤을 때는, "Async all the way"라는 원칙을 지키지 않아 발생하는 버그라고 생각했습니다. 그래서, ^^ 제가 덧글로 질문자에게 요청한 대로 재현 코드를 세심하게 작성하다 보면 스스로 오류를 발견해 낼 거라 생각했는데요, 음... 제가 틀렸습니다. ^^;

일단, 질문을 먼저 다시 볼까요? 우선, 다음의 코드는 우리가 원래 기대했던 대로 동작합니다.

public async Task Start()
{
    while (true)
    {
        Socket client = await server.AcceptAsync();
        Console.WriteLine(client.RemoteEndPoint);
        ReadAsync2(client); // await 없이 호출한 것에 유의!
    }
}

private async Task ReadAsync2(Socket client)
{
    byte[] buffer = new byte[256];
    while (true)
    {
        int n1 = await client.ReceiveAsync(buffer, SocketFlags.None);
        Console.WriteLine(n1);
    }
}

이때의 스레드 흐름을 따라가 볼까요? Start 메서드를 호출한 스레드를 "A" 스레드라고 설명하면,

1. [A] Start 진입
2. [A] AcceptAsync 비동기 메서드 호출
3. 이후 A 스레드는 Start 메서드를 벗어나, (아마도) 스레드 풀로 반환

1. 클라이언트 연결, 스레드 풀에서 [B] 스레드가 선택돼 AcceptAsync 이후의 코드를 처리하기 시작
2. [B] Console.WriteLine(client.RemoteEndPoint);
3. [B] ReadAsync2 호출
4. [B] ReceiveAsync 비동기 메서드 호출
5. 이후 B 스레드는 ReadAsync2 함수를 벗어나,
6. [B] Start 메서드의 while 문을 반복

위와 같이 진행됩니다. 따라서 이후의 클라이언트 접속도 받아들여 소켓 통신이 가능하게 됩니다. 여기에 대해서는 별다른 이견이 없겠죠?




문제는, ReadAsync2에 Poll 호출을 추가했을 때입니다.

private async Task ReadAsync2(Socket client)
{
    byte[] buffer = new byte[256];
    while (true)
    {
        client.Poll(1000 * 1000 * 5, SelectMode.SelectRead);

        int n1 = await client.ReceiveAsync(buffer, SocketFlags.None);
        Console.WriteLine(n1);
    }
}

이렇게 하면, 이후 AcceptAsync 실행이 안 돼 두 번째부터 접속하는 소켓에 대해서는 처리를 할 수 없습니다. 도대체, 왜 이런 일이 발생하는 걸까요? ^^

만약, 아래의 글을 잘 읽어 이해했던 분이라면, 저 과정이 신기하지 않았을 것입니다.

C# - async/await 그리고 스레드 (1) MyTask로 재현
; https://www.sysnet.pe.kr/2/0/13055

위의 글에서 제가 await로 호출하는 TestAsync 메서드의 내부 구현이 천차만별이라고 했습니다. 즉, 동기 호출이 될 수도 있고 비동기 호출이 될 수도 있다는 것을 언급했는데요, 바로 이러한 상황이 이번 질문의 Poll 메서드로 인해 발생한 부작용을 설명합니다.

소켓의 Poll 메서드는,

Socket.Poll Method
; https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.poll

SelectMode.SelectRead 인자로 호출한 경우 데이터가 소켓의 입력 버퍼에 존재할 때까지 (첫 번째 인자로 넣은 시간 동안) "대기"를 하는 동기 호출입니다. 답이 되었나요? ^^

즉, Poll 메서드의 호출 결과 소켓의 입력 버퍼에 반드시 데이터가 존재하게 됩니다. 이로 인해, 이후의 ReceiveAsync는 이미 입력 버퍼에 데이터가 있기 때문에 비동기 호출을 하지 않고 동기 호출로 곧바로 제어를 반환하게 됩니다. 따라서, 마치 while 루프가 다음과 같은 식으로 동작하는 결과를 낳습니다.

while (true)
{
    client.Poll(1000 * 1000 * 5, SelectMode.SelectRead);

    int n1 = client.Receive(buffer, SocketFlags.None); // ReceiveAsync가 동기 호출로 반환되므로!
    Console.WriteLine(n1);
}

그러니까, 계속해서 while 루프를 돌게 돼 이후의 Accept 단계로 나아가질 못하는 것입니다. 이해되셨나요? 이해가 안 되셨다면 "C# - async/await 그리고 스레드 (1) MyTask로 재현" 글을 다시 한번 잘 보셔야 합니다.

이때의 스레드 흐름을 정리하면 다음과 같습니다.

1. [A] Start 진입
2. [A] AcceptAsync 비동기 메서드 호출
3. 이후 A 스레드는 Start 메서드를 벗어나, (아마도) 스레드 풀로 반환

1. 클라이언트 연결, 스레드 풀에서 [B] 스레드가 선택돼 AcceptAsync 이후의 코드를 처리하기 시작
2. [B] Console.WriteLine(client.RemoteEndPoint);
3. [B] ReadAsync2 호출
4. [B] ReceiveAsync 메서드 호출 (동기)
5. [B] ReadAsync2의 while 루프 반복




그렇다면, 동일한 예제를 .NET Framework 4.8로 실행했을 때는 Poll을 호출했는데도 왜? ReceiveAsync가 비동기로 동작해 Accept 호출까지 잘 진행이 된 것일까요?

그건 .NET Framework과 .NET Core/5+의 ReceiveAsync에 대한 내부 구현이 다르기 때문입니다. .NET Core/5+의 경우에는 ReceiveAsync가 위에서 설명한 것처럼 소켓 버퍼에 데이터가 있을 땐 비동기 대기를 하지 않고 곧바로 버퍼의 내용을 읽어 동기식으로 동작하도록 구현하고 있습니다.

반면, .NET Framework의 ReceiveAsync는 소켓 버퍼에 내용이 있어도 무조건 비동기로 동작하도록 구현하고 있습니다. 이에 대한 확인을 Thread ID를 Console.WriteLine에 넣어보면 알 수 있습니다.

private static async void ReadAsync(Socket client)
{
    byte[] buffer = new byte[256];
    while (true)
    {
        bool poll = client.Poll(1000 * 1000 * 5, SelectMode.SelectRead);
        Console.WriteLine($"{Thread.CurrentThread.ManagedThreadId}"): {poll}");

        int n1 = await client.ReceiveAsync(new ArraySegment<byte>(buffer, 0, 256), SocketFlags.None);
        Console.WriteLine($"{Thread.CurrentThread.ManagedThreadId}"): {n1}");
    }
}

위의 코드를 .NET Core/5+에서 실행하면 ReceiveAsync를 기준으로 위/아래 모두 동일한 스레드 ID가 출력됩니다. 반면, .NET Framework에서 실행하면 위/아래의 스레드가 달라집니다.

이해가 좀 되셨을까요? ^^




이 사실을 알았다면, 해당 문제는 좀 새롭게 봐야 합니다. ReceiveAsync는 소켓 입력을 언제 받을지 모르니 그 사이 대기하는 스레드 자원을 좀 더 효율적으로 사용하기 위해 비동기 호출을 하는 것인데요, 그 대기 시간을 앞서 호출한 Poll에서 잡아버려 스레드를 비효율적으로 묶어버리고 있습니다. 애당초 ReceiveAsync를 호출할 이유가 없게 되는 것인데요, 따라서 Poll 호출을 해야 한다면 그다음에 오는 ReceiveAsync는 그냥 Receive로 바꾸는 것이 코드를 읽는데 더 직관적입니다.

사실 여기서 더 근본적인 문제는 AcceptAsync 이후 ReadAsync2를 호출한 것입니다. ReadAsync2의 내부 구현에 상관 없이 그것은 동기 호출이기 때문에 이후의 Accept를 호출하는데 방해를 합니다. 따라서 이런 경우 ReadAsync2를 위한 호출을 (질문자의 재현 코드에 명시한 것처럼) 처음부터 스레드 풀에 맡겨 (또는 명시적으로 스레드를 생성해) 처리하는 것이 더 바람직합니다.

public async Task Start()
{
    while (true)
    {
        Socket client = await server.AcceptAsync();
        Console.WriteLine(client.RemoteEndPoint);
        Task.Run( () => ReadAsync2(client) );
    }
}




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/27/2024]

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

비밀번호

댓글 작성자
 



2022-10-09 11시54분
[kss] await 호출이 100% 비동기라고 단정 지으면 안되겠네요. 특히 poll 때문에 receiveAsync가 동기로 호출된다는건 쉽게 생각못할거같습니다. 좋은 지식 얻고갑니다^^
[guest]

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13868정성태1/17/20253109Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20254045오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20254248개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20253941오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20253892Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20253342Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20253616Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20253907Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20253599디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20253954디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20254100개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
13857정성태1/7/20254137C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경파일 다운로드1
13856정성태1/6/20253711디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
13855정성태12/28/20244444오류 유형: 941. Golang - os.StartProcess() 사용 시 오류 정리
13854정성태12/27/20244543C/C++: 186. Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경파일 다운로드1
13853정성태12/26/20244023디버깅 기술: 213. Windbg - swapgs 명령어와 (Ring 0 커널 모드의) FS, GS Segment 레지스터
13852정성태12/25/20244468디버깅 기술: 212. Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터파일 다운로드1
13851정성태12/23/20244228디버깅 기술: 211. Windbg - 커널 모드 디버깅 상태에서 사용자 프로그램을 디버깅하는 방법
13850정성태12/23/20244725오류 유형: 940. "Application Information" 서비스를 중지한 경우, "This file does not have an app associated with it for performing this action."
13849정성태12/20/20244874디버깅 기술: 210. Windbg - 논리(가상) 주소를 Segmentation을 거쳐 선형 주소로 변경
13848정성태12/18/20244817디버깅 기술: 209. Windbg로 알아보는 Prototype PTE파일 다운로드2
13847정성태12/18/20244840오류 유형: 939. golang - 빌드 시 "unknown directive: toolchain" 오류 빌드 시 이런 오류가 발생한다면?
13846정성태12/17/20245052디버깅 기술: 208. Windbg로 알아보는 Trans/Soft PTE와 2가지 Page Fault 유형파일 다운로드1
13845정성태12/16/20244524디버깅 기술: 207. Windbg로 알아보는 PTE (_MMPTE)
13844정성태12/14/20245195디버깅 기술: 206. Windbg로 알아보는 PFN (_MMPFN)파일 다운로드1
13843정성태12/13/20244381오류 유형: 938. Docker container 내에서 빌드 시 error MSB3021: Unable to copy file "..." to "...". Access to the path '...' is denied.
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...