Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 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) );
    }
}




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/6/2023]

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)
13237정성태1/30/20234409.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20234165개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20233766개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20234706개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20235939오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234025스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233021오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20233318개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20234162.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20234296.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20234023개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20233701.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233067개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20233352Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20233581오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20233281개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20233529Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20233634오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20233154Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20233101VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20233657디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20233933디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
13215정성태1/11/20235223Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법 [1]
13214정성태1/10/20235050.NET Framework: 2087. .NET 6부터 SourceGenerator와 통합된 System.Text.Json [1]파일 다운로드1
13213정성태1/9/20234525오류 유형: 836. docker 이미지 빌드 시 "RUN apt install ..." 명령어가 실패하는 이유
13212정성태1/8/20234301기타: 85. 단정도/배정도 부동 소수점의 정밀도(Precision)에 따른 형변환 손실
1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...