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