C# - Console 프로젝트에서의 await 대상으로 Main 스레드 활용하는 방법
이런 질문이 있었군요,
.NET Console 프로젝트에서의 ThreadPool 낭비?
; https://forum.dotnetdev.kr/t/net-console-threadpool/11660
답글도 많이 달리고 좀 어지러워졌지만, 그래도 대충 이해 차원에서 제 나름대로 설명을 해보겠습니다.
예제를 곁들여 설명해 볼까요? ^^
internal class Program
{
// C# 7.1부터 추가된 async Main
static async Task Main(string[] args)
{
await Task.Delay(1000);
Console.WriteLine("Hello World!");
}
}
위와 같은 코드를 수행하면, Main을 실행했던 최초 스레드(이하 편의상 Main 스레드)는 await 호출 이후 "응용 프로그램의 종료"를 막기 위해 대기 상태로 전환합니다. 사실, 저 코드는 C# 컴파일러에 의해 다음과 같이 변환되는데요,
internal class Program
{
static void Main(string[] args)
{
TaskMain(args).GetAwaiter().GetResult();
}
static async Task TaskMain(string[] args) // 원래 Main의 코드를 빼서 정의
{
await Task.Delay(1000);
Console.WriteLine("Hello World!");
}
}
결국, Main이 Task를 반환했던 것은 C# 컴파일러의 syntactic sugar에 불과한 것으로, 실제로는 async가 아닙니다. 따라서 호출상으로는, Main 스레드는 무조건 대기 상태로 머물고 개발자가 작성한 코드들은 내부의 await 호출을 타고 흐르면서 ThreadPool의 스레드에서 (아래에서 설명하겠지만, 마치 점프하듯이) 실행됩니다.
질문자의 의견처럼, Main 스레드가 그저 놀고 있는 것이 맞습니다.
그런데, 질문 자체에서 혼란스러운 것이 하나 있으므로 그것을 먼저 정리해야 합니다. 그것은 "async/await" 대상이 1) 비동기 I/O 작업인지, 2) CPU 바운드 작업인지에 따라서 다르게 동작한다는 것입니다.
위에서 작성한 예제 코드에서 Task.Delay(1000)는 비동기 I/O 작업과 유사합니다. 반면 CPU 바운드 작업인 경우에는... 음... 간단하게 소수를 체크하는 코드를 들 수 있습니다.
namespace ConsoleApp1;
internal class Program
{
static async Task Main(string[] args)
{
await Task.Delay(1000);
Console.WriteLine("Hello World!");
bool result = await IsPrime(100000000003);
Console.WriteLine(result);
}
// http://www.dotnetperls.com/prime
public static Task<bool> IsPrime(long candidate)
{
Task<bool> task = Task.Run(() =>
{
if ((candidate & 1) == 0)
{
return (candidate == 2) ? true : false;
}
for (int i = 3; (i * i) <= candidate; i += 2)
{
if ((candidate % i) == 0)
{
return false;
}
}
return candidate != 1;
});
return task;
}
}
자, 그럼 위의 2가지 상황을 두고 질문에 있던 "2번 상황"을 다시 보면,
2. await를 1번 사용
Main Thread 1개 노는 중
B,C,D Thread 대기 중
A Thread 사용 중
"A Thread 사용 중"이라는 표현이 2가지 상황에서 나뉩니다.
1) 비동기 I/O 작업에 준하는 Task.Delay에 await을 걸었을 때는 "A Thread 사용 중"이라고 표현한 것은 맞지 않습니다. 왜냐하면 Main 스레드는 Task.Delay 내부의 타이머를 호출한 후 그에 대한 타이머 완료 이벤트가 발생할 때까지 기다리지 않고 바로 Delay 메서드를 벗어나 GetAwaiter().GetResult()를 호출하게 됩니다. 즉, 1초 동안은 Main 스레드만 대기 상태로 빠져 있을 뿐 ThreadPool의 어떠한 스레드도 사용 중이지 않습니다.
그러다, 1초 후 타이머 완료 이벤트가 발생하면 이후의 작업, 즉 "Console.WriteLine(...);" 코드를 수행하기 위해 ThreadPool의 여유 스레드를 하나 빌려와 코드 수행을 계속합니다. (참고: "
C# - async/await 그리고 스레드 (3) Task.Delay 재현")
2) 반면 CPU 바운드 작업을 수행하는 await IsPrime의 호출에서는 그 작업을 Task.Run으로 맡겼기 때문에 그것이 "A Thread"로 표현될 수 있습니다. 이런 경우라면, 최초 호출된 await의 Task.Run으로 인한 스레드가 사실상 Main 스레드를 대신해 "사용 중"인 효과를 가집니다.
대충 이해가 되셨을까요? 위의 설명을 이해했다면, "async/await 호출"의 장점이라는 것이 "비동기 I/O 작업"에 대해서만 효과적이라는 것을 알 수 있습니다.
CPU 바운드 작업에 대해서는, CPU 코어가 남는 경우에는 효과적일 수 있지만 웹 사이트와 같은 상황이라면, 가령 16개의 코어를 가진 머신이라고 해도 16번의 요청만 오면 CPU가 100% 사용 중이기 되기 때문에 "await 호출"의 장점이 전혀 없습니다.
그런 의미에서 "Thread Pool의 자원인 Thread를 계속해서 하나를 점유"하는 상황은 "비동기 I/O 작업"에서는 발생하지 않습니다. await 호출을 한 ThreadPool의 스레드는 곧바로 ThreadPool에 반환되고, 일정 시간 후 비동기 I/O의 완료 이벤트를 받으면 다시 ThreadPool의 스레드를 빌려와 await 이후의 코드를 수행하는 식입니다. (위에서 이런 상황을 "마치 점프하듯이"라고 언급한 이유입니다.) 물론, 비동기 I/O가 빠르게 작업을 끝낸다면 I/O 대기로 인한 끊김이 작아 "거의 1개의 스레드"가 점유된다고 볼 수도 있습니다. 또한, File I/O의 ReadAsync를 최초 호출한 경우 비동기 I/O가 수행될 수 있지만, cache로 인해 이후의 ReadAsync 호출을 하는 경우에는 커널에서 곧바로 데이터를 반환하는 상황도 발생하는데 그럴 때는 await 호출이 그냥 동기 호출 방식처럼 동작하므로 이후의 코드 수행을 ReadAsync를 호출했던 그 스레드가 계속 이어서 진행합니다. (이처럼
종종 await 호출이 동기로 실행하는 경우가 있습니다.)
하지만 현실적으로 봤을 때, 여러분의 컴퓨터에 실행 중인 프로그램들 중에서 CPU 100%를 치고 있는 것이 얼마나 될까요? 즉, 다른 수많은 프로그램들도 Main 스레드는 할 일 없이 장시간 대기하며 낭비(?)하고 있었던 것입니다.
일단 설명의 집중을 위해, 이후로는 async/await 호출을 "비동기 I/O 작업"에 대해 호출한다는 것을 가정으로 설명을 계속하겠습니다.
그런데, 이와 함께 "
SynchronizationContext"가 언급이 되고 있는데요, 재미있게도 "SynchronizationContext는 dotnet의 디자인 결함"이라는 의견이 나왔습니다. 하지만 이것은 디자인 결함이 아닌, 마이크로소프트가 애써서 구현을 더 추가한 유형이라고 봐야 합니다.
단적으로, SynchronizationContext가 없었다면 아래의 코드조차도,
namespace WinFormsApp1;
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private async void Form1_Load(object sender, EventArgs e)
{
await Task.Delay(1000); // Delay 완료 후 ThreadPool의 스레드가 이후 작업을 수행
this.Text = "Hello World!"; // 스레드가 달라지므로 (디버깅 시) 예외 발생 - System.InvalidOperationException: 'Cross-thread operation not valid: Control 'Form1' accessed from a thread other than the thread it was created on.'
}
}
예외가 발생하게 됩니다. 되려 이것을 막기 위해 개발자가 일일이 모든 코드에
Invoke 코드를 심어야 하는데요,
private async void Form1_Load(object sender, EventArgs e)
{
await Task.Delay(1000);
// SynchronizationContext가 없었다면 await 이후의 모든 UI 접근 코드를 이렇게 바꿔야 함
this.Invoke(new Action(() =>
{
this.Text = "Hello World!";
}));
}
엄밀히 말해서 저게 정말 디자인 결함이라고 생각한다면, 지금 당장이라도 SynchronizationContext를 사용하지 않도록 다음과 같이 코드를 추가하면 됩니다.
public partial class Form1 : Form
{
public Form1()
{
// SynchronizationContext를 사용하지 않도록 설정
SynchronizationContext.SetSynchronizationContext(null);
InitializeComponent();
}
private async void Form1_Load(object sender, EventArgs e)
{
// ...[생략]...
}
}
그럼, 그동안 누렸던 SynchronizationContext의 고마움을 (await 호출을 할 때마다) 비로소 느끼게 될 것입니다.
SynchronizationContext가 주로 UI Framework에 구현된 이유는, Windows 운영체제 자체가 UI 자원에 대해 thread-safe하게 구현하지 않았기 때문입니다.
그렇다면 오히려 SynchronizationContext가 아닌, UI 자원을 thread-safe하게 구현하지 않은 Windows의 디자인 결함일까요?
사실, 이 문제를 너무 어렵게 생각할 필요가 없습니다. 보통 코딩을 할 때 상태 유지를 위해 전역 변수를 두거나 할 텐데요, 바로 그것이 thread-safe와 직접적인 연관이 되는 것입니다. 혹시 여러분은 일상적으로 만드는 클래스를 thread-safe하게 만드시나요? 일례로, DTO 성격으로 만들어진 클래스들의 멤버를 접근하는데 lock/critical section을 걸어 모두 보호하진 않을 것입니다.
다시 말해, 어떤 식으로든 상태 유지가 필요한 경우에는 결국 thread-safe 문제와 엮이게 되는데요, 대표적으로 화면에 항상 떠 있는 UI 관련 요소들이 상태를 가져야 하는 전형적인 사례들입니다. 물론, 그 요소들의 상태 변경 코드에 일일이 lock/critical section을 거는 코드를 사용해도 되겠지만, 성능 및 lock의 남용으로 인한 dead-lock 등의 이유로 그렇게 하지 않는 것이 일반적입니다.
유사한 사례로, .NET BCL에 포함된 숱한 타입들의 instance 메서드는 모두 thread-safe하지 않다는 것을 알 것입니다. (반면, static 메서드는 일반적으로 thread-safe하게 만듭니다.)
그러니까, thread-safe하지 않은 것이 Windows의 디자인 결함이라고 볼 수는 없습니다. 실제로 이게 꼭 윈도우만 그런 것도 아닌데요, 가령 Android(일례로,
Java.Lang.IllegalStateException)도, iOS도 UI 요소를 다른 스레드에서 건드리는 경우 예외가 발생합니다.
정리해 보면, UI 요소는 다른 스레드에서 접근하는 경우 상태가 불안정해질 수 있고, 그렇다면 await과 같은 호출 이후에 ThreadPool의 여유 스레드가 작업을 계속 이어나가는 상황에서 개발자는 일일이 Control.Invoke 등의 코드를 넣어야 합니다. 바로 그런 상황에서 나온 SynchronizationContext의 도입은 개발자에게 축복과도 같은 것입니다. (물론, 이것이 뒤단에서 자동으로 처리되기 때문에
오히려 혼란으로 이어지기도 합니다.)
그렇다면, ASP.NET (.NET Framework)은 왜 SynchronizationContext를 구현했을까요?
ASP.NET의 경우, 초기 모델부터 (WinForms와 유사하게) WebForms 프레임워크를 도입했습니다. 재미있게도 HTML로 렌더링하는 "서버 컨트롤"들을 제공했는데요, 이러한 서버 컨트롤을 바탕으로 화면
하나의 요청에 대해 Page를 대응시켜 처리합니다.
그리고, 그 페이지를 처리하는 동안 Thread가 바뀌는 일이 없습니다. 즉, 요청을 받은 그 스레드가 Page의 렌더링까지 모두 담당하는 것입니다.
그렇다면, 그런 상황에서 Page 및 서버 컨트롤이 굳이 thread-safe한 코드로 작성해야 했을까요? 당연히 그렇지 않을 것입니다. 또한, 스레드 하나가 요청을 전담하기에, 그 스레드를 SynchronizationContext의 대상 스레드로 쉽게 정할 수 있다는 특징이 있습니다.
하지만 애써 SynchronizationContext를 ASP.NET에 도입한 노력에도 불구하고, 여러분 중에 그것을 사용해 보신 분은 거의 없었을 거라고 봅니다. 즉, 제공은 했지만 현실적으로는 잘 사용되지 않았습니다. (아마도 마이크로소프트 스스로, 아니면 당시에 특수한 3rd-party Web Control을 제공하는 업체들의 소수 개발자들만 사용했을 것입니다.)
그러던 것이,
ASP.NET Core에 오면서는 SynchronizationContext가 사라졌습니다. 왜 그럴까요? 우선, Web Forms 프레임워크 자체가 ASP.NET Core에는 없습니다. 그리고 결정적으로 ASP.NET Core는 그 자체가 비동기입니다. 즉, 요청을 받은 스레드가 응답까지 책임지지 않고 중간에 얼마든지 바뀔 수 있는 구조입니다. 따라서, SynchronizationContext의 대상으로 결정할 수 있는 마땅한 스레드 후보가 없습니다.
이제 다시 원래의 주제로 돌아가 볼까요? ^^
그럼 Main 스레드를 낭비하지 않는 방법이 무엇일까요? 쉽게는, 비동기 호출 후 다른 할 일이 있다면 그것에 Main 스레드를 활용하면 됩니다. 코드도 매우 간단한데요,
static void Main(string[] args)
{
Task task = TaskMain(args);
while (task.IsCompleted == false)
{
// do something
Thread.Sleep(1000);
}
}
static async Task TaskMain(string[] args)
{
await Task.Delay(1000);
Console.WriteLine("Hello World!");
}
Main 스레드에서 await 호출이 아닌, 그냥 Task로 받은 후 부가 작업을 처리하도록 만들면 됩니다. 물론, 이 방법으로는 억지로 뭔가를 해야 하도록 만들어야 하기 때문에 어떤 식으로든 Main 스레드가 낭비되는 것은 사실입니다.
다른 방법으로는, Console의 Main 스레드를 활용하도록 SynchronizationContext를 만들어주면 됩니다. 해당 설계는 확장이 가능하도록 만들어졌기 때문에,
.NET Framework: 2077. C# - 직접 만들어 보는 SynchronizationContext
; https://www.sysnet.pe.kr/2/0/13191
직접 만들어도 되고, 아니면 누군가가 이미 그 용도로 만들어 준 타입을 사용해도 됩니다.
Console/Service Application을 위한 SynchronizationContext - AsyncContext
; https://www.sysnet.pe.kr/2/0/12231
위의 글에 소개한
Nito.AsyncEx 라이브러리를 사용해 다음과 같이 코딩하면,
using Nito.AsyncEx;
namespace ConsoleApp2;
// Install-Package Nito.AsyncEx
internal class Program
{
static void Main(string[] args)
{
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
AsyncContext.Run(AsyncMain);
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
}
static async Task<int> AsyncMain()
{
await Task.Delay(1000);
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
return 0;
}
}
화면에는 ManagedThreadId의 출력으로 모두 "1"이 나오는 것을 확인할 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]