🌒 C# Thread/Task

💫 lock

---

private readonly object thisLock = new object();
lock (thisLock)
{
	// Bla Bla
}

임계 영역 (Critical Section)을 만들어주는 키워드
Thread는 lock을 얻어야 Critical Secion을 생성할 수 있다.

외부 코드에서도 접근할 수 있는 this, Type 형식 (typeof, GetType()), string 형식은 매개변수로 절대 사용하지 말 것.

@ Key, 전용 개체 인스턴스
@ Critical Section, 한 번에 한 스레드만 접근할 수 있는 코드 영역

💫 스레드

---

메모리 가상화
메모리가 없는데 있는척 하는것
디스크를 써서 메모리가 적은데 많은척 하는것

CPU 가상화
CPU가 없는데 있는척 하는것

윈도우95 이전
윈도우 OS에 스레드가 하나밖에 없었음
프로그램 하나가 무한루프에빠지만 다른 프로그램도 멈춤
CPU를 나눠써야 하는데 하나밖에 없어서 그러지 못함
한 프로그램이 무한루프를 돌면 다른 프로그램에도 영향

그래서 CPU 가상화
이제 CPU를 쓰지 말고 스레드 써
스레드를 CPU처럼 써

프로세스에게 스레드를 나눠주고
그 스레드가 어플리케이션 입장에서는 마치 CPU인것처럼 사용

이제 여러 개니까, 한 스레드가 무한루프에 빠져도 다른 스레드는 멈추지 않음
다른 스레드는 자신에게 주어진 스레드를 사용

🫧 스레드는 가벼운 자원인가?

상대적으로 프로세스보다 가볍지만,
절대적으로 무거운 리소스이다.

• 공간비용
  • Thread Kernel Object
    • x86 : 700B
    • x64 : 1240B
    • ARM : 350B
  • Thread Environment Block : 4K
  • User Mode stack : 1MB
  • Kernel Mode stack
    • 32bit OS : 12KB
    • 64bit OS : 24KB
  • 총 : 1053KB 남짓
• 시간비용
  • DLL Thread attach/detach notification
    • 프로세스에 스레드를 만들어질때마다, 각 DLL의 main 함수를 호출
    • 문안인사를 하는 것이지요, 스레드 새로 만들어졌어요
    • DLL은 스레드를 위한 공간을 마련
    • 대표적인게 C Runtime Library (DLL)
  • Context Switching
    • 이 스레드가 갖고 있던 가상의 CPU 정보들을 로드해서 수행하고
    • 일정 시간 (Quantum)이 지나면 다시 저장하고
    • 다음 스레드를 로드…
  • -> DLL이 많으면 많을수록, 스레드가 많으면 많을수록
    

🫧 이제 그만 해야 할 바보짓

🫧 명시적으로 스레드를 생성하지 말라

• 예외
  • 보통 단계의 스레드 우선순위가 아닌 스레드가 필요한 경우
  • 포그라운드 스레드처럼 동작하는 스레드가 필요한 경우
  • 계산 중심의 작업이 상당히 오랫동안 수행되어야 하는 경우

가능한 Thread class를 이용하여 명시적으로 스레드를 생성하지 말 것

🫧 여러 스레드를 사용하는 이유

• 응답성의 개선
  • 클라이언트 측 UI 어플리케이션
  • UI 스레드
  • 작업 스레드의 개수는 늘어나지만, 응답성이 개선되므로 전체적으로 좀 더 나은 응용 프로그램으로 판단
• 성능
  • 클라이언트, 서버 측 Application
  • 다중 CPUI에 한해서 성능 개선
• 스레드를 가장 잘 화용하는 방법
  • 스레드 풀을 이용하고 비동기로 작업을 수행하라
  • -> 우리가 TASK 병렬화를 알아야 하는 이유
    

🫧 계산 중심 비동기 작업

• CLR 스레드 풀
  • 사실 이미 만들어져 있음
  • 명시적으로 쓰지않고 있었을 뿐
  • Requests Queue에 작업이 들어오면, 그때 스레드를 할당
  • 최대한 하나만 쓰려고함
    • 많이 들어오면, 코어 수만큼만 스레드를 만들어서 사용
  • Request Queue에 작업이 일정시간 들어오지 않으면 스레드를 제거
    • 생성/제거 비용 최소화
      

🫧 QueueUserWorkItem

public static bool QueueUserWorkItem(WaitCallback callBack, object state);

for (int i = 0; i < 100; i++)
{
	ThreadPool.QueueUserWorkItem((obj) =>
	{
		Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
	});
}

Console.ReadLine();

• 작업 완료 시점을 알 수 없음
• 작업 수행 결과를 얻어 올 수 없음
• 취소 / 예외 처리 불가능
• -> 쓰기 쉽지만 이런 한계들 때문에 잘 안씀
  

🫧 Task

Task 나누면 장접
Taks 간의 상관관계가 없다면, 병렬로 수행 가능 -> 빨라진다

// QueueUserWorkItem과 유사 동작을 수행하는 코드 패턴
Action action = () =>
{
	Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
};

Task task = new Task(action); // #1: Task 객체 생성 후
task.Start(); // Start 명시적 호출

Task.Run(action); // #2: Task.Run을 이용하여 작업 수행

// 결과 값을 가져오는 Task 객체 생성, Sum 호출 시 예외가 발생한다면?
Task<int> task = new Task<int>((n) => Sum((int)n), 100);
t.Start(); // 명시적 수행
t.Wait(); // Task 완료 대기 (완료 시점을 알 수 있다)

Console.WrtieLine(t.Result); // t.Result 결과 획득 (결과를 받아올 수 있다)

Canceling a Task

private static int Sum(CancellationToken ct, int n)
{
	int sum = 0;
	for (; n > 0; n--)
	{
		// 작업 취소가 요청되면 OperationCanceledException을
		// innerException으로 갖는 AggregateException을 던짐
		ct.ThrowIfCancellationRequested();
		checked
		{
			sum += n;
		}
	}
	return sum;
}

static void Main(string[] args)
{
	CancellationTokenSource cts = new CancellationTokenSource();
	Task<Int32> t = Task.Run(() => Sum(cts.Token, 100000000), cts.Token);
	cts.Cancel(); // 작업 취소 요청

	try
	{
		Console.WriteLine("The result is: " + t.Result);
	}
	catch (AggregateException e)
	{
		e.Handle((innerException) => innerException is OperationCanceledException);
		// Operation.. 이면 처리된 것으로  

		Console.WriteLine("Exception: " + e.InnerExceptions[0].Message);
	}
}

• 작업 완료 시점을 알 수 있음
• 작업 수행 결과를 얻어 올 수 있음
• 취소 / 예외 처리 가능
  

🫧 Task 연결1

// 웨이팅 아키텍처
Task<int> task = new Task<int>((n) => Sum((int)n), 100);
t.Start();
t.Wait(); // 대기

Console.WrtieLine(t.Result);

to

// waitfree, lockfree 아키텍처 (서버에서 많이 사용)

// t Task가 완료되면 cwt Task를 수행
Task<Int32> t = Task.Run(() => Sum(CancellationTokenSource.None, 100));
Task cwt = t.ContinueWith( // 완료되면
(antecedent) =>
{
	Console.WriteLine("The result is: " + antecedent.Result);
});

// 연결하고 바로 빠져나옴

🫧 Task 연결2

// TaskContinuationOptions
// OnlyOnCanceled, OnlyOnFaulted, OnlyOnRanToCompletion 그외 기타 등등

CancellationTokeSource cts = new CancellationTokenSource();
cts.Cancel();

Task<Int32> t = Task.Run(() => Sum(cts.Token, 100000000), cts.Token);

t.ContinueWith((task) => // 성공 완료시
{
	Console.WriteLine("The result is: " + task.Result);
}, TaskContinuationOptions.OnlyOnRanToCompletion);
t.ContinueWith((task) => // 실패/예외 발생 시
{
	Console.WriteLine("The task failed" + task.Exception.InnerException);
}, TaskContinuationOptions.OnlyOnFaulted);
t.ContinueWith((task) => // 취소시
{
	Console.WriteLine("The task was canceled");
}, TaskContinuationOptions.OnlyOnCanceled);

🫧 Task 연결3

// Parent-Child Task로의 연결, TaskCreationOptions.AttachedToParent
Task<Int32[]> parent = new Task<Int32[]>(() =>
{
	var results = new Int32[3];
	new Task(() => results[0] = Sum(CancellationToken.None, 10000), TaskCreationOptions.AttachedToParent).Start();
	new Task(() => results[1] = Sum(CancellationToken.None, 20000), TaskCreationOptions.AttachedToParent).Start();
	new Task(() => results[2] = Sum(CancellationToken.None, 30000), TaskCreationOptions.AttachedToParent).Start();
	return results;
});

// Child Task들이 모두 완료되면 = parent가 완료되면

var cwt = parent.ContinueWith((parentTask) => // parentTask가 끝나면 수행할 Task 연결
{
	Array.ForEach(parentTask.Result, Console.WriteLine);
});

parent.Start();

🫧 I/O 중심의 비동기 작업

🫧 동기 I/O 매커니즘

🫧 비동기 I/O 매커니즘

• 비동기
  • 작업을 하는 주체와 작업을 요청하는 주체가 다름
  • 작업을 하는 주체가 작업을 요청하는 주체에게 알려주는 방식
    • (H/W가 완료하면 스레드에게 노티피케이션을 줌)

이를 어떻게 패턴화하느냐?

🫧 Comparing Patterns

• Sync

public int Read(byte[] buffer, int offset, int count);
// 근데 비동기가 좋잖아?

• APM (Asynchronous Programming Model)

public IAsyncResult BeginRead(byte[] buffer, int offset, int count, AsyncCallback callback, object state);
public int EndRead(IAsyncResult asyncResult);
// 비동기 : 시키는 방식과 결과를 취하는 방식이 다름
// 문제 : 매개변수가 많아짐, 받을 때도 복잡하고, EndRead를 언제 호출해야 할지 애매함

// 좀 더 쉬운 방법?

• EAP (Event-based Asynchronous Pattern)

public void ReadAsync(byte[] buffer, int offset, int count);
public event ReadCompletedEventHandler ReadCompleted;

// 결과를 취하는 방식을 이벤트로
// 문제 : APM, EAP 둘 다 작업을 시키는 위치와 받는 위치가 다름
// (호출하는 쪽과 결과를 받아 처리하는 함수(콜백) 사이에 컨텍스트를 넘기기 위해 지역변수나 매개변수를 만들어 넘겨야 함)

• TAP (Task-based Asynchronous Pattern)

public Task<int> ReadAsync(byte[] buffer, int offset, int count);

Sync, TAP 간의 메서드 원형이 가장 유사함.
-> 가장 직관적이고, Sync 방식과 닮아 있어 사용하기 쉬운 비동기 패턴

🫧 Async/Await

내부 동작
async 메서드는 Task를 반환
await 키워드는 Task를 받아서 Task가 완료될 때까지 대기
await 키워드는 Task가 완료되면 Task의 결과를 반환

// 실수 조심 !!
// 이건 함수가 체인되어 있어서, 첫번째 함수가 끝나야 두번째 함수가 실행됨
await SomeMethodAsync();
await SomeMethodAsync();

// ConfigureAwait(false)를 쓰면 첫번째 함수가 끝나기 전에 두번째 함수가 실행됨
await SomeMethodAsync().ConfigureAwait(false);
await SomeMethodAsync().ConfigureAwait(false);

// 아니면 Task를 먼저 받아서, 그걸 await
Task t = SomeMethodAsync();
Task t2 = SomeMethodAsync();
await t;
await t2;

// WhenAll을 쓸 수도 있음
await Task.WhenAll(t, t2);

// WhenAny를 쓸 수도 있음
var tasks = new List<Task>() { t, t2 };
while (tasks.Count > 0)
{
	Task t = await Task.WhenAny(tasks);
	tasks.Remove(t);
}

💫 Ref

참고 : ‘C#을 이용한 Task 병렬화와 비동기 패턴’
참고 : ‘C# 비동기 사용 예제(Task, WhenAll, WhenAny)’
참고 : ‘C# 비동기/대기/작업 설명(심층 분석)’

밑 단계는 똑같지만
조금 추상화해보면
스레드는 포그라운드 스레드와 백그라운드 스레드로 나뉨
포그라운드 스레드가 종료되지 않으면 프로세스가 종료되지 않음
백그라운드 스레드는 프로세스가 종료되면 종료됨

Delegate : 내부적으로 오브젝팅을 합니다만, 오브젝트안에 콜백 함수에 관한 포인터를 가지고 있는 타입

비트레벨 parallel
데이터 parallel
task parallel

Task.Delay(1000); Task.Run(() => { });

async 키워드를 쓰면
함수가 상태머신으로 변환됨

상태머신은 함수가 실행되는 동안 상태를 저장하고, 다시 실행될 때 상태를 복원하는 것

💫 동기/비동기

---

🫧 동기

Synchrounous

메소드를 호출한 이후, 메소드가 종료될 때까지 코드 실행이 차단됨
즉, 작업은 순서대로 실행되므로 하나의 작업이 끝나야 다음 작업을 수행할 수 있음

🫧 비동기

Asynchronous

메소드를 호출한 이후 해당 메서드가 종료되지 않아도 코드 기다리지 않고 다음 코드 실행
비동기 메서드는 백그라운드 스레드에서 수행되므로, 메인스레드는 다른 작업을 수행할 수 있음