.NET: 멀티스레딩 및 비동기 작업을 위한 도구입니다. 1 부

나는 Habr에 원본 기사를 게시하고 있으며 그 번역본은 기업에 게시되어 있습니다. 블로그.

지금 여기서 결과를 기다리지 않고 비동기식으로 작업을 수행하거나 이를 수행하는 여러 단위에서 대규모 작업을 분할해야 하는 필요성은 컴퓨터가 출현하기 전에도 존재했습니다. 그들의 출현으로 이러한 필요성은 매우 명백해졌습니다. 2019년인 지금, 저는 8개 이상의 프로세스가 병렬로 실행되고 더 많은 스레드가 실행되는 8코어 Intel Core 프로세서가 탑재된 노트북에서 이 글을 작성하고 있습니다. 근처에는 몇 년 전에 구입한 약간 허름한 전화기가 있는데, 그 전화기에는 16코어 프로세서가 탑재되어 있습니다. 주제별 리소스에는 작성자가 20코어 프로세서를 탑재한 올해의 주력 스마트폰을 칭찬하는 기사와 비디오가 가득합니다. MS Azure는 시간당 128달러 미만의 비용으로 2코어 프로세서와 XNUMXTB RAM을 갖춘 가상 머신을 제공합니다. 불행하게도 스레드의 상호 작용을 관리할 수 없으면 최대치를 추출하고 이 기능을 활용하는 것이 불가능합니다.

전문 용어

프로세스 - 격리된 주소 공간인 OS 개체에는 스레드가 포함되어 있습니다.
실 - OS 개체, 실행의 가장 작은 단위, 프로세스의 일부, 스레드는 프로세스 내에서 메모리 및 기타 리소스를 공유합니다.
멀티 태스킹 - OS 속성, 여러 프로세스를 동시에 실행하는 기능
멀티코어 - 프로세서의 속성, 데이터 처리를 위해 여러 코어를 사용하는 기능
다중 처리 - 컴퓨터의 속성, 물리적으로 여러 프로세서와 동시에 작업할 수 있는 능력
멀티스레딩 — 프로세스의 속성, 여러 스레드에 데이터 처리를 분산시키는 기능입니다.
병행 - 단위 시간당 여러 작업을 동시에 물리적으로 수행
비동기 — 이 처리가 완료될 때까지 기다리지 않고 작업을 실행하며, 실행 결과는 나중에 처리될 수 있습니다.

은유

모든 정의가 좋은 것은 아니며 일부는 추가 설명이 필요하므로 공식적으로 소개된 용어에 아침 식사 요리에 대한 비유를 추가하겠습니다. 이 비유에서 아침 식사를 요리하는 것은 하나의 과정입니다.

아침에 아침식사를 준비하면서 나는 (CPU) 나는 부엌에 온다 (컴퓨터). 나는 손이 2개 있다(코어). 주방에는 다양한 기기가 있습니다(IO): 오븐, 주전자, 토스터, 냉장고. 가스를 켜고 그 위에 프라이팬을 올려놓고 예열될 때까지 기다리지 않고 기름을 부어줍니다(비동기식, Non-Blocking-IO-Wait), 냉장고에서 계란을 꺼내서 접시에 담은 다음 한 손으로 치십시오 (스레드#1), 두 번째 (스레드#2) 접시(공유 자원)를 들고 있습니다. 이제 주전자를 켜고 싶은데 손이 부족해요.스레드 기아) 이 시간 동안 프라이팬이 가열되어(결과 처리 중) 휘핑한 것을 붓습니다. 나는 주전자에 손을 뻗어 전원을 켜고 어리석게도 물이 끓는 것을 지켜봅니다.차단-IO-대기), 비록 이 시간 동안 그는 오믈렛을 휘젓는 접시를 씻을 수 있었지만.

두 손만으로 오믈렛을 요리했고 그 이상은 없지만 동시에 오믈렛을 휘젓는 순간 오믈렛 휘핑, 접시 잡기, 프라이팬 가열의 세 가지 작업이 한 번에 이루어졌습니다. CPU는 컴퓨터에서 가장 빠른 부분이고, IO는 모든 것이 느려지는 경우가 가장 많기 때문에 IO에서 데이터를 수신하는 동안 CPU를 무언가로 점유하는 것이 효과적인 솔루션인 경우가 많습니다.

계속해서 비유하자면 다음과 같습니다.

• 오믈렛을 만드는 과정에서 옷도 갈아입어본다면, 이는 멀티태스킹의 한 예가 될 것이다. 중요한 뉘앙스: 컴퓨터는 사람보다 이 분야에서 훨씬 뛰어납니다.
• 예를 들어 레스토랑의 여러 요리사가 있는 주방 - 멀티 코어 컴퓨터.
• 쇼핑 센터의 푸드 코트에 있는 많은 레스토랑 - 데이터 센터

.NET 도구

.NET은 다른 많은 것들과 마찬가지로 스레드 작업에 능숙합니다. 새로운 버전이 나올 때마다 작업을 위한 점점 더 많은 새로운 도구, 즉 OS 스레드에 대한 새로운 추상화 계층이 도입됩니다. 추상화 구성 작업을 할 때 프레임워크 개발자는 높은 수준의 추상화를 사용할 때 하나 이상의 수준 아래로 내려갈 수 있는 기회를 제공하는 접근 방식을 사용합니다. 대부분의 경우 이는 필요하지 않습니다. 실제로 산탄총으로 자신의 발을 쏘는 문이 열리지만 때로는 드문 경우지만 현재 추상화 수준에서 해결되지 않는 문제를 해결하는 유일한 방법일 수 있습니다. .

도구란 프레임워크와 타사 패키지에서 제공하는 API(응용 프로그래밍 인터페이스)는 물론 멀티스레드 코드와 관련된 문제 검색을 단순화하는 전체 소프트웨어 솔루션을 의미합니다.

스레드 시작하기

Thread 클래스는 스레드 작업을 위한 .NET의 가장 기본적인 클래스입니다. 생성자는 두 대리자 중 하나를 허용합니다.

• ThreadStart — 매개변수 없음
• ParametrizedThreadStart - 객체 유형의 매개변수가 하나 있습니다.

Start 메서드를 호출한 후 새로 생성된 스레드에서 대리자가 실행됩니다. ParametrizedThreadStart 형식의 대리자가 생성자에 전달된 경우 개체가 Start 메서드에 전달되어야 합니다. 이 메커니즘은 로컬 정보를 스트림으로 전송하는 데 필요합니다. 스레드를 생성하는 것은 비용이 많이 드는 작업이며 스레드 자체는 적어도 스택에 1MB의 메모리를 할당하고 OS API와의 상호 작용이 필요하기 때문에 무거운 개체라는 점은 주목할 가치가 있습니다.

new Thread(...).Start(...);

ThreadPool 클래스는 풀의 개념을 나타냅니다. .NET에서 스레드 풀은 엔지니어링의 일부이며 Microsoft 개발자는 다양한 시나리오에서 최적으로 작동하도록 많은 노력을 기울였습니다.

일반 개념:

애플리케이션이 시작되는 순간부터 백그라운드에서 예비 스레드를 여러 개 생성하고 이를 사용할 수 있는 기능을 제공합니다. 스레드가 자주 그리고 대량으로 사용되는 경우 풀은 호출자의 요구 사항을 충족하도록 확장됩니다. 적시에 풀에 사용 가능한 스레드가 없으면 스레드 중 하나가 반환될 때까지 기다리거나 새 스레드를 생성합니다. 따라서 스레드 풀은 일부 단기 작업에는 적합하지만 전체 애플리케이션 작업에서 서비스로 실행되는 작업에는 적합하지 않습니다.

풀의 스레드를 사용하기 위해 ParametrizedThreadStart와 동일한 시그니처를 갖는 WaitCallback 유형의 대리자를 허용하는 QueueUserWorkItem 메서드가 있으며 여기에 전달된 매개 변수는 동일한 기능을 수행합니다.

ThreadPool.QueueUserWorkItem(...);

덜 알려진 스레드 풀 메서드 RegisterWaitForSingleObject는 비차단 IO 작업을 구성하는 데 사용됩니다. 이 메서드에 전달된 대리자는 메서드에 전달된 WaitHandle이 "Released"일 때 호출됩니다.

ThreadPool.RegisterWaitForSingleObject(...)

.NET에는 스레드 타이머가 있으며 처리기가 풀에서 가져온 스레드에서 호출된다는 점에서 WinForms/WPF 타이머와 다릅니다.

System.Threading.Timer

실행을 위해 풀의 스레드에 대리자를 보내는 다소 색다른 방법인 BeginInvoke 메서드도 있습니다.

DelegateInstance.BeginInvoke

위의 여러 메서드를 호출할 수 있는 함수인 Kernel32.dll Win32 API의 CreateThread에 대해 간략하게 설명하겠습니다. extern 메소드의 메커니즘 덕분에 이 함수를 호출하는 방법이 있습니다. 나는 레거시 코드의 끔찍한 예에서 그러한 호출을 단 한 번 본 적이 있으며, 정확히 이것을 한 작성자의 동기는 여전히 나에게 미스터리로 남아 있습니다.

Kernel32.dll CreateThread

스레드 보기 및 디버깅

사용자가 만든 스레드, 모든 타사 구성 요소 및 .NET 풀은 Visual Studio의 스레드 창에서 볼 수 있습니다. 이 창은 응용 프로그램이 디버그 상태이고 중단 모드에 있을 때만 스레드 정보를 표시합니다. 여기에서 각 스레드의 스택 이름과 우선 순위를 편리하게 확인하고 디버깅을 특정 스레드로 전환할 수 있습니다. Thread 클래스의 Priority 속성을 사용하면 OC와 CLR이 스레드 간에 프로세서 시간을 나눌 때 권장 사항으로 인식하는 스레드의 우선 순위를 설정할 수 있습니다.

태스크 병렬 라이브러리

TPL(작업 병렬 라이브러리)은 .NET 4.0에 도입되었습니다. 이제 이는 비동기 작업을 위한 표준이자 주요 도구입니다. 이전 접근 방식을 사용하는 모든 코드는 레거시로 간주됩니다. TPL의 기본 단위는 System.Threading.Tasks 네임스페이스의 Task 클래스입니다. 작업은 스레드에 대한 추상화입니다. 새로운 버전의 C# 언어를 사용하면 작업(async/await 연산자)을 사용하여 작업할 수 있는 우아한 방법이 생겼습니다. 이러한 개념 덕분에 비동기 코드를 간단하고 동기적인 것처럼 작성할 수 있게 되었고, 스레드의 내부 작동에 대해 거의 이해하지 못한 사람이라도 이를 사용하는 애플리케이션, 긴 작업을 수행할 때 멈추지 않는 애플리케이션을 작성할 수 있게 되었습니다. async/await 사용은 하나 또는 여러 기사의 주제이지만 몇 문장으로 요점을 파악해 보겠습니다.

• async는 Task 또는 void를 반환하는 메서드의 수정자입니다.
• 그리고 wait는 비차단 작업 대기 연산자입니다.

다시 한 번 말씀드리지만, 일반적인 경우(예외가 있음) wait 연산자는 현재 실행 스레드를 추가로 해제하고 작업이 실행을 마치면 스레드(실제로 컨텍스트를 말하는 것이 더 정확합니다)를 해제합니다. , 나중에 자세히 설명) 메서드를 계속해서 실행합니다. .NET 내에서 이 메커니즘은 작성된 메서드가 전체 클래스로 바뀔 때 항복 반환과 동일한 방식으로 구현됩니다. 이는 상태 머신이며 이러한 상태에 따라 별도의 조각으로 실행될 수 있습니다. 관심 있는 사람은 누구나 asynс/await를 사용하여 간단한 코드를 작성하고, 컴파일러 생성 코드가 활성화된 JetBrains dotPeek을 사용하여 어셈블리를 컴파일하고 볼 수 있습니다.

Task를 시작하고 사용하기 위한 옵션을 살펴보겠습니다. 아래 코드 예제에서는 유용하지 않은 새 작업을 만듭니다(스레드.수면(10000)), 그러나 실제 생활에서는 CPU를 많이 사용하는 복잡한 작업이어야 합니다.

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Code of action will be executed on other context
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    //  Code after await will be executed on captured context
}

태스크는 다음과 같은 다양한 옵션으로 생성됩니다.

• LongRunning은 작업이 빨리 완료되지 않을 것이라는 힌트입니다. 즉, 풀에서 스레드를 가져오는 것이 아니라 다른 사람에게 해를 끼치지 않도록 이 작업에 대해 별도의 스레드를 생성하는 것이 좋습니다.
• AttachedToParent - 작업을 계층 구조로 정렬할 수 있습니다. 이 옵션을 사용하는 경우 Task는 자체적으로 완료되어 하위 항목의 실행을 기다리는 상태일 수 있습니다.
• PreferFairness - 실행을 위해 전송된 태스크를 나중에 전송하기 전에 먼저 실행하는 것이 더 낫다는 것을 의미합니다. 그러나 이는 단지 권장사항일 뿐이며 결과는 보장되지 않습니다.

메서드에 전달된 두 번째 매개 변수는 CancellationToken입니다. 작업이 시작된 후 작업 취소를 올바르게 처리하려면 실행 중인 코드를 CancellationToken 상태에 대한 검사로 채워야 합니다. 검사가 없으면 CancellationTokenSource 개체에서 호출된 Cancel 메서드는 작업이 시작되기 전에만 작업 실행을 중지할 수 있습니다.

마지막 매개변수는 TaskScheduler 유형의 스케줄러 개체입니다. 이 클래스와 그 하위 항목은 스레드 전체에 작업을 배포하기 위한 전략을 제어하도록 설계되었습니다. 기본적으로 작업은 풀의 임의 스레드에서 실행됩니다.

Wait 연산자는 생성된 작업에 적용됩니다. 즉, 그 뒤에 작성된 코드가 대기 전의 코드와 동일한 컨텍스트(종종 동일한 스레드에서 실행됨)에서 실행된다는 의미입니다.

메서드는 async void로 표시됩니다. 즉, wait 연산자를 사용할 수 있지만 호출 코드는 실행을 기다릴 수 없습니다. 이러한 기능이 필요한 경우 메서드는 Task를 반환해야 합니다. async void로 표시된 메서드는 매우 일반적입니다. 일반적으로 이는 화재 및 망각 원칙에 따라 작동하는 이벤트 핸들러 또는 기타 메서드입니다. 실행이 끝날 때까지 기다릴 수 있는 기회를 제공하고 결과를 반환해야 하는 경우 Task를 사용해야 합니다.

StartNew 메서드가 반환한 작업과 다른 모든 작업에서 false 매개 변수를 사용하여 ConfigureAwait 메서드를 호출할 수 있습니다. 그런 다음 대기 후 실행은 캡처된 컨텍스트가 아닌 임의의 컨텍스트에서 계속됩니다. 이는 대기 후 코드에 대해 실행 컨텍스트가 중요하지 않은 경우 항상 수행되어야 합니다. 이는 라이브러리에 패키지되어 제공될 코드를 작성할 때 MS에서 권장하는 사항이기도 합니다.

작업 완료를 기다리는 방법에 대해 좀 더 자세히 살펴보겠습니다. 다음은 기대가 조건적으로 잘 수행되는 경우와 조건적으로 잘못 수행되는 경우에 대한 설명이 포함된 코드의 예입니다.

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // good

    result = AsyncMethod().Result; // bad

    AsyncMethod().Wait(); // bad

    IEnumerable<Task> tasks = new Task[] {
        AsyncMethod(), OtherAsyncMethod()
    };

    await Task.WhenAll(tasks); // good
    await Task.WhenAny(tasks); // good

    Task.WaitAll(tasks.ToArray()); // bad
}

첫 번째 예에서는 호출 스레드를 차단하지 않고 작업이 완료될 때까지 기다립니다. 결과가 이미 있는 경우에만 결과 처리로 돌아갑니다. 그때까지 호출 스레드는 자체 장치에 남아 있습니다.

두 번째 옵션에서는 메서드 결과가 계산될 때까지 호출 스레드를 차단합니다. 이는 프로그램의 귀중한 리소스인 스레드를 단순한 유휴 상태로 점유했을 뿐만 아니라 우리가 호출하는 메서드의 코드에 대기가 포함되어 있고 동기화 컨텍스트가 이후 호출 스레드로 반환해야 하기 때문에 좋지 않습니다. 기다리면 교착 상태가 발생합니다. 호출 스레드는 비동기 메서드의 결과가 계산될 때까지 기다리고, 비동기 메서드는 호출 스레드에서 실행을 계속하려고 시도하지만 실패합니다.

이 접근 방식의 또 다른 단점은 복잡한 오류 처리입니다. 사실 async/await를 사용할 때 비동기 코드의 오류는 처리하기가 매우 쉽습니다. 오류는 코드가 동기인 것처럼 동일하게 동작합니다. Task에 동기식 대기 엑소시즘을 적용하면 원래 예외는 AggregateException으로 변합니다. 예외를 처리하려면 InnerException 유형을 검사하고 C# 세계에서 더 친숙한 catch 블록 체인 대신 하나의 catch 블록 내에 if 체인을 직접 작성하거나 catch when 구문을 사용해야 합니다.

세 번째와 마지막 예제도 같은 이유로 불량으로 표시되었으며 모두 동일한 문제를 포함하고 있습니다.

WhenAny 및 WhenAll 메서드는 작업 그룹을 기다리는 데 매우 편리합니다. 작업 그룹을 하나로 래핑하여 그룹의 작업이 처음 트리거되거나 모든 작업이 실행을 완료했을 때 실행됩니다.

스레드 중지

다양한 이유로 흐름이 시작된 후 흐름을 중지해야 할 수도 있습니다. 이를 수행하는 방법에는 여러 가지가 있습니다. Thread 클래스에는 적절하게 이름이 지정된 두 가지 메서드가 있습니다. 유산 и 인터럽트. 첫 번째는 사용을 권장하지 않습니다. 임의의 순간에 호출한 후 명령을 처리하는 동안 예외가 발생합니다. ThreadAbortedException. 정수 변수를 증가시킬 때 이러한 예외가 발생할 것이라고는 예상하지 않습니다. 그렇죠? 그리고 이 방법을 사용하면 이는 매우 실제적인 상황입니다. CLR이 코드의 특정 섹션에서 이러한 예외를 생성하지 못하도록 해야 하는 경우 이를 호출로 래핑할 수 있습니다. Thread.BeginCriticalRegion, Thread.EndCriticalRegion. finally 블록에 작성된 모든 코드는 이러한 호출로 래핑됩니다. 이러한 이유로 프레임워크 코드의 깊이에서 빈 try가 있는 블록을 찾을 수 있지만 finally는 비어 있지 않습니다. Microsoft는 이 방법을 너무 권장하지 않아 .net 코어에 포함하지 않았습니다.

인터럽트 방법은 더 예측 가능하게 작동합니다. 예외로 인해 스레드를 중단할 수 있습니다. ThreadInterruptedException 스레드가 대기 상태에 있는 순간에만 가능합니다. WaitHandle, 잠금을 기다리는 동안 또는 Thread.Sleep을 호출한 후 정지되는 동안 이 상태로 들어갑니다.

위에 설명된 두 옵션 모두 예측 불가능성으로 인해 좋지 않습니다. 해결책은 구조를 사용하는 것입니다. 취소 토큰 그리고 수업 취소 토큰 소스. 요점은 다음과 같습니다. CancellationTokenSource 클래스의 인스턴스가 생성되고 이를 소유한 사람만 메서드를 호출하여 작업을 중지할 수 있습니다. 취소. CancellationToken만 작업 자체에 전달됩니다. CancellationToken 소유자는 작업을 직접 취소할 수 없으며 작업이 취소되었는지 여부만 확인할 수 있습니다. 이에 대한 부울 속성이 있습니다. 취소요청됨 및 방법 ThrowIfCancel요청됨. 후자는 예외를 발생시킵니다 TaskCancelledException Parroting 중인 CancellationToken 인스턴스에서 Cancel 메서드가 호출된 경우. 그리고 이것이 제가 추천하는 방법입니다. 이는 예외 작업을 중단할 수 있는 지점을 완전히 제어함으로써 이전 옵션에 비해 개선된 것입니다.

스레드를 중지하는 가장 잔인한 옵션은 Win32 API TerminateThread 함수를 호출하는 것입니다. 이 함수를 호출한 후 CLR의 동작을 예측할 수 없습니다. MSDN에는 이 함수에 대해 다음과 같은 내용이 기록되어 있습니다. “TerminateThread는 가장 극단적인 경우에만 사용해야 하는 위험한 기능입니다. “

FromAsync 메서드를 사용하여 레거시 API를 작업 기반으로 변환

태스크가 도입된 후 시작되어 대부분의 개발자에게 조용한 공포감을 안겨준 프로젝트를 운 좋게 작업할 수 있다면 타사 API와 팀 API 모두를 포함한 많은 오래된 API를 처리할 필요가 없습니다. 과거에 고문을 가한 적이 있다. 운 좋게도 .NET Framework 팀이 우리를 돌봐주었지만 아마도 목표는 우리 자신을 돌보는 것이었을 것입니다. 그러나 .NET에는 기존 비동기 프로그래밍 방식으로 작성된 코드를 새로운 코드로 쉽게 변환할 수 있는 다양한 도구가 있습니다. 그 중 하나가 TaskFactory의 FromAsync 메서드입니다. 아래 코드 예제에서는 이 메서드를 사용하여 WebRequest 클래스의 이전 비동기 메서드를 작업으로 래핑합니다.

object state = null;
WebRequest wr = WebRequest.CreateHttp("http://github.com");
await Task.Factory.FromAsync(
    wr.BeginGetResponse,
    we.EndGetResponse
);

이것은 단지 예일 뿐이며 기본 제공 유형을 사용하여 이 작업을 수행할 필요는 없지만 기존 프로젝트에는 IAsyncResult를 반환하는 BeginDoSomething 메서드와 이를 수신하는 EndDoSomething 메서드가 넘쳐납니다.

TaskCompletionSource 클래스를 사용하여 레거시 API를 작업 기반으로 변환

고려해야 할 또 다른 중요한 도구는 클래스입니다. 작업완료소스. 기능, 목적, 작동 원리 측면에서 보면 위에서 언급한 ThreadPool 클래스의 RegisterWaitForSingleObject 메서드와 다소 유사할 수 있습니다. 이 클래스를 사용하면 기존 비동기 API를 작업에서 쉽고 편리하게 래핑할 수 있습니다.

이러한 목적을 위해 고안된 TaskFactory 클래스의 FromAsync 메서드에 대해 이미 이야기했다고 말할 것입니다. 여기서 우리는 Microsoft가 지난 15년 동안 제공한 .net의 비동기 모델 개발의 전체 역사를 기억해야 합니다. TAP(작업 기반 비동기 패턴) 이전에는 APP(비동기 프로그래밍 패턴)가 있었습니다. 방법에 관한 것이었어 시작DoSomething이 돌아오고 있습니다. IAsyncResult 및 방법 종료이를 받아들이는 DoSomething과 지난 몇 년 동안 FromAsync 메서드는 완벽했지만 시간이 지나면서 이벤트 기반 비동기 패턴(EAP), 비동기 작업이 완료되면 이벤트가 발생한다고 가정했습니다.

TaskCompletionSource는 이벤트 모델을 중심으로 구축된 작업 및 레거시 API를 래핑하는 데 적합합니다. 해당 작업의 본질은 다음과 같습니다. 이 클래스의 개체에는 Task 유형의 공용 속성이 있으며, 해당 상태는 TaskCompletionSource 클래스의 SetResult, SetException 등 메서드를 통해 제어될 수 있습니다. 이 Task에 Wait 연산자가 적용된 위치에서는 TaskCompletionSource에 적용된 메서드에 따라 예외가 발생하여 실행되거나 실패합니다. 여전히 명확하지 않다면 일부 이전 EAP API가 TaskCompletionSource를 사용하여 작업에 래핑된 이 코드 예제를 살펴보겠습니다. 이벤트가 발생하면 작업이 완료됨 상태로 전환되고 대기 연산자를 적용한 메서드가 표시됩니다. 이 태스크는 객체를 수신한 후 실행을 재개합니다. 결과.

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

작업완료소스 팁 & 요령

TaskCompletionSource를 사용하여 이전 API를 래핑하는 것이 전부는 아닙니다. 이 클래스를 사용하면 스레드를 차지하지 않는 작업에 대한 다양한 API를 설계할 수 있는 흥미로운 가능성이 열립니다. 그리고 우리가 기억하는 것처럼 스트림은 값 비싼 리소스이며 그 수는 주로 RAM 양에 따라 제한됩니다. 이러한 제한은 예를 들어 복잡한 비즈니스 로직이 포함된 로드된 웹 애플리케이션을 개발함으로써 쉽게 달성될 수 있습니다. Long-Polling과 같은 트릭을 구현할 때 내가 말하는 가능성을 고려해 보겠습니다.

요컨대 트릭의 본질은 다음과 같습니다. API 측에서 발생하는 일부 이벤트에 대한 정보를 API로부터 받아야 하는 반면, API는 어떤 이유로 이벤트를 보고할 수 없고 상태만 반환할 수 있습니다. 이에 대한 예는 WebSocket 시대 이전이나 어떤 이유로 이 기술을 사용하는 것이 불가능했을 때 HTTP 위에 구축된 모든 API입니다. 클라이언트는 HTTP 서버에 요청할 수 있습니다. HTTP 서버 자체는 클라이언트와의 통신을 시작할 수 없습니다. 간단한 해결책은 타이머를 사용하여 서버를 폴링하는 것이지만 이로 인해 서버에 추가 로드가 발생하고 평균 TimerInterval/2에 추가 지연이 발생합니다. 이 문제를 해결하기 위해 Long Polling이라는 트릭이 발명되었습니다. 제한 시간이 만료되거나 이벤트가 발생할 때까지 서버에 보관됩니다. 이벤트가 발생하면 처리되고, 그렇지 않으면 요청이 다시 전송됩니다.

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

그러나 그러한 솔루션은 이벤트를 기다리는 클라이언트 수가 증가하자마자 끔찍한 것으로 판명될 것입니다. 왜냐하면... 이러한 각 클라이언트는 이벤트를 기다리는 전체 스레드를 차지합니다. 예, 그리고 이벤트가 트리거될 때 추가로 1ms의 지연이 발생합니다. 대부분의 경우 이는 중요하지 않지만 소프트웨어를 가능한 것보다 더 나쁘게 만드는 이유는 무엇입니까? Thread.Sleep(1)을 제거하면 하나의 프로세서 코어를 100% 유휴 상태로 로드하여 쓸모 없는 주기로 회전하게 됩니다. TaskCompletionSource를 사용하면 이 코드를 쉽게 다시 만들고 위에서 식별된 모든 문제를 해결할 수 있습니다.

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

이 코드는 프로덕션 준비가 되어 있지 않으며 단지 데모일 뿐입니다. 실제 사례에서 이를 사용하려면 최소한 아무도 예상하지 않는 시간에 메시지가 도착하는 상황을 처리해야 합니다. 이 경우 AsseptMessageAsync 메서드는 이미 완료된 작업을 반환해야 합니다. 이것이 가장 일반적인 경우라면 ValueTask 사용을 고려해 볼 수 있습니다.

메시지에 대한 요청을 받으면 TaskCompletionSource를 생성하여 사전에 배치한 다음 먼저 어떤 일이 일어날지 기다립니다. 지정된 시간 간격이 만료되거나 메시지가 수신됩니다.

ValueTask: 왜 그리고 어떻게

항복 반환 연산자와 같은 async/await 연산자는 메서드에서 상태 시스템을 생성하며 이는 거의 항상 중요하지 않지만 드물게 문제를 일으킬 수 있는 새 개체를 생성합니다. 이 경우는 정말 자주 호출되는 메서드일 수 있는데, 초당 수만, 수십만 건의 호출을 이야기하고 있는 셈입니다. 이러한 메서드가 대부분의 경우 모든 Wait 메서드를 우회하여 결과를 반환하는 방식으로 작성된 경우 .NET에서는 이를 최적화하는 도구인 ValueTask 구조를 제공합니다. 명확하게 하기 위해 사용 예를 살펴보겠습니다. 우리가 자주 사용하는 캐시가 있습니다. 그 안에 몇 가지 값이 있으면 간단히 반환하고, 그렇지 않은 경우 느린 IO로 이동하여 가져옵니다. 나는 후자를 비동기식으로 수행하고 싶습니다. 이는 전체 메서드가 비동기식으로 판명되었음을 의미합니다. 따라서 메소드를 작성하는 확실한 방법은 다음과 같습니다.

public async Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return val;
    return await RequestById(id);
}

약간의 최적화를 원하고 Roslyn이 이 코드를 컴파일할 때 생성할 결과에 대한 약간의 두려움 때문에 이 예제를 다음과 같이 다시 작성할 수 있습니다.

public Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return Task.FromResult(val);
    return RequestById(id);
}

실제로 이 경우 최적의 솔루션은 핫 패스를 최적화하는 것입니다. 즉, 불필요한 할당 및 GC 로드 없이 사전에서 값을 얻는 것입니다. 드문 경우지만 여전히 데이터를 위해 IO로 이동해야 합니다. , 모든 것이 예전 방식대로 플러스/마이너스로 유지됩니다.

public ValueTask<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return new ValueTask<string>(val);
    return new ValueTask<string>(RequestById(id));
}

이 코드 부분을 자세히 살펴보겠습니다. 캐시에 값이 있으면 구조를 만들고, 그렇지 않으면 실제 작업이 의미 있는 작업으로 래핑됩니다. 호출 코드는 이 코드가 실행된 경로를 신경 쓰지 않습니다. C# 구문 관점에서 ValueTask는 이 경우 일반 Task와 동일하게 동작합니다.

TaskSchedulers: 작업 시작 전략 관리

다음으로 고려하고 싶은 API는 클래스입니다. 작업 스케줄러 그리고 그 파생상품. 위에서 TPL에는 스레드 전체에 작업을 배포하기 위한 전략을 관리하는 기능이 있다고 이미 언급했습니다. 이러한 전략은 TaskScheduler 클래스의 자손에 정의됩니다. 필요한 거의 모든 전략을 라이브러리에서 찾을 수 있습니다. 병렬 확장 추가 기능, Microsoft에서 개발했지만 .NET의 일부는 아니지만 Nuget 패키지로 제공됩니다. 그 중 일부를 간단히 살펴보겠습니다.

• CurrentThreadTaskScheduler — 현재 스레드에서 작업을 실행합니다.
• LimitedConcurrencyLevelTaskScheduler — 생성자에서 허용되는 매개변수 N으로 동시에 실행되는 작업 수를 제한합니다.
• OrderedTaskScheduler — LimitedConcurrencyLevelTaskScheduler(1)로 정의되므로 작업이 순차적으로 실행됩니다.
• 일훔치기TaskScheduler - 구현 일을 훔치는 것 작업 분배에 접근합니다. 본질적으로 별도의 ThreadPool입니다. .NET에서 ThreadPool은 모든 애플리케이션에 대해 하나의 정적 클래스이므로 프로그램의 한 부분에서 오버로드되거나 잘못 사용되면 다른 부분에서 부작용이 발생할 수 있다는 문제를 해결합니다. 더욱이, 그러한 결함의 원인을 이해하는 것은 극히 어렵다. 저것. ThreadPool 사용이 공격적이고 예측 불가능할 수 있는 프로그램 부분에서는 별도의 WorkStealingTaskSchedulers를 사용해야 할 수도 있습니다.
• 대기 중인 작업 스케줄러 — 우선순위 대기열 규칙에 따라 작업을 수행할 수 있습니다.
• ThreadPerTask스케줄러 — 실행되는 각 작업에 대해 별도의 스레드를 생성합니다. 완료하는 데 예측할 수 없을 정도로 오랜 시간이 걸리는 작업에 유용할 수 있습니다.

자세하게 잘 나와있어요 기사 Microsoft 블로그의 TaskSchedulers에 대해 알아보세요.

작업과 관련된 모든 것을 편리하게 디버깅하기 위해 Visual Studio에는 작업 창이 있습니다. 이 창에서 작업의 현재 상태를 확인하고 현재 실행 중인 코드 줄로 이동할 수 있습니다.

PLinq 및 Parallel 클래스

Tasks 및 이에 대해 언급된 모든 것 외에도 .NET에는 PLinq(Linq2Parallel) 및 Parallel 클래스라는 두 가지 흥미로운 도구가 더 있습니다. 첫 번째는 여러 스레드에서 모든 Linq 작업의 병렬 실행을 약속합니다. 스레드 수는 WithDegreeOfParallelism 확장 메서드를 사용하여 구성할 수 있습니다. 안타깝게도 기본 모드의 PLinq에는 상당한 속도 향상을 제공할 만큼 데이터 소스 내부에 대한 정보가 충분하지 않은 경우가 많습니다. 반면에 시도 비용은 매우 낮습니다. 먼저 AsParallel 메서드를 호출하면 됩니다. Linq 메서드 체인을 실행하고 성능 테스트를 실행합니다. 또한 파티션 메커니즘을 사용하여 데이터 소스의 특성에 대한 추가 정보를 PLinq에 전달할 수도 있습니다. 더 읽어보실 수 있습니다 여기에 и 여기에.

Parallel 정적 클래스는 Foreach 컬렉션을 병렬로 반복하고, For 루프를 실행하고, 병렬 Invoke에서 여러 대리자를 실행하는 메서드를 제공합니다. 계산이 완료될 때까지 현재 스레드의 실행이 중지됩니다. ParallelOptions를 마지막 인수로 전달하여 스레드 수를 구성할 수 있습니다. 옵션을 사용하여 TaskScheduler 및 CancellationToken을 지정할 수도 있습니다.

조사 결과

보고서 자료와 이후 작업하면서 수집한 정보를 바탕으로 이 글을 쓰기 시작했을 때, 이렇게 많은 내용이 있을 것이라고는 예상하지 못했습니다. 이제 내가 이 글을 쓰고 있는 텍스트 편집기가 15페이지가 사라졌다고 비난하면서 중간 결과를 요약하겠습니다. 다른 트릭, API, 시각적 도구 및 함정은 다음 기사에서 다루겠습니다.

결론 :

• 최신 PC의 리소스를 사용하려면 스레드, 비동기 및 병렬 처리를 위한 도구를 알아야 합니다.
• .NET에는 이러한 목적을 위한 다양한 도구가 있습니다.
• 모든 API가 한꺼번에 나타나는 것은 아니기 때문에 레거시 API를 종종 찾을 수 있지만, 많은 노력을 들이지 않고도 오래된 API를 변환할 수 있는 방법이 있습니다.
• .NET에서 스레드 작업은 Thread 및 ThreadPool 클래스로 표현됩니다.
• Thread.Abort, Thread.Interrupt 및 Win32 API TerminateThread 메서드는 위험하므로 사용하지 않는 것이 좋습니다. 대신 CancellationToken 메커니즘을 사용하는 것이 더 좋습니다.
• 흐름은 귀중한 자원이며 공급이 제한되어 있습니다. 스레드가 이벤트를 기다리느라 바쁜 상황은 피해야 합니다. 이를 위해 TaskCompletionSource 클래스를 사용하는 것이 편리합니다.
• 병렬 처리 및 비동기 작업을 위한 가장 강력하고 진보된 .NET 도구는 작업입니다.
• C# async/await 연산자는 비차단 대기 개념을 구현합니다.
• TaskScheduler 파생 클래스를 사용하여 스레드 간 작업 배포를 제어할 수 있습니다.
• ValueTask 구조는 핫 패스 및 메모리 트래픽을 최적화하는 데 유용할 수 있습니다.
• Visual Studio의 작업 및 스레드 창은 다중 스레드 또는 비동기 코드를 디버깅하는 데 유용한 많은 정보를 제공합니다.
• PLinq는 멋진 도구이지만 데이터 소스에 대한 정보가 충분하지 않을 수 있지만 파티셔닝 메커니즘을 사용하여 이 문제를 해결할 수 있습니다.
• 계속 될 ...

출처 : habr.com