C# Task(await/async)와 Thread의 알맞은 사용처는 무엇인가요?

성능의 이점을 제외하고 (thread 생성 비용 등…)

단순히 어떤 내용을 어떤 것으로 구현하면 편리하다 정도로 생각했을 때,
C#에서 Thread는 주로 어떤 기능에서 사용하나요?

아무래도 C++ 위주로 하다 보니 (c++17 이전) task보다는 thread에 손이 자주 가게 되는데 요즘은 task 위주로 구현하려고 노력합니다…
그럼에도 thread를 사용한다고 하면 주로 어느 곳에 사용하시나요?

Thread

Thread를 비동기으로 사용하는데 있어서 핵심적인 책임은 3가지로 구분됩니다.

  1. Thread의 할당

  2. Thread의 종료

  3. Thread의 작업

Thread 를 직접 사용하시려면, 이 3가지에 작업이 모든 예외 상황들에 안정적으로 진행 될 수 있도록

이것들을 모두 직접 작성하셔야 하는 책임이 개발자에게 부여됩니다.

필연적으로 try-catch 문이나, finally 블록을 사용하여 이러한 책임을 수행하셔야 합니다.

실질적 비즈니스 로직과 무관한 지저분하고 복잡한 indent 들과 보이러플레이트들이 따라오게 됩니다.

Task / async / await

반면에, await Task 을 사용하게 되면 단순히 sugar-syntax 로서의 편리함도 있지만 그 보다도

  1. Thread의 할당

  2. Thread의 종료

  3. Thread의 작업

1. 2. 에 대한 직접 구현으로부터 개발자를 해방해주고,

실질적으로 비즈니스 로직을 수행하기 위한 3. 에만 집중할 수 있게 해줍니다.

그에 따른 개발생산성 면에서의 개선은 당연히 따라오겠죠.

사실 상 근래의 닷넷 환경에서는 Thread 를 직접 사용하는 경우는 드물어졌고,

개인적으로는 특정 작업에 대해 반복작업의 책임을 갖는 Worker 클래스 내부적으로 종종 사용하고는 합니다.

8 Likes

@BOBx5 님의 답변에 이어서 좀 더 사족을 달아보자묜.,…

최종적으로는 Task 역시 thread 를 이용합니다. 주로 thead pool 의 thread 를 이용하게 되는데 이것 역시 용도에 따라 제어할 수 있어요.
(SynchronizationContext 등등을 이용해서…)

따라서 Task 와 thread 를 같은 레벨의 완전히 다른 무언가로 비교할 것은 아니고
thread 의 안전하고 쉬운 사용추상화 지원을 위해 thread 를 랩핑한 것이 Task 이다… 정도로 말할 수 있겠군요.

게다가 현재는 thread 를 단독으로 사용하는 것 자체가
문법적으로나 성능면에서나 관리면에서 Task 사용에 비해 이점이 하나도 없기 때문에
매우 특수한 상황을 제외하고 이제는 thread 는 잊어주셔도 됩니다.
전부 Task 로 사용하시면 됩니다.
(마지막 문장은 제 뇌피셜입니닷 ㅋㅅㅋ)

특히나 async / await 을 사용한다면 thread 는 더더욱 사용할 수 없기 때문에
모던한 닷넷 작업에서는 thread 직접 사용은 없다… 라고 봐도 됩니다.
(그냥 상식선에서 개념만 이해하면 됩니다.)

4 Likes