.NET: Инструменти за работа с многопоточност и асинхронност. Част 1

Публикувам оригиналната статия на Habr, чийто превод е публикуван в корпоративния публикация в блога.

Необходимостта да се направи нещо асинхронно, без да се чака резултатът тук и сега, или да се раздели голяма работа между няколко единици, които я изпълняват, съществуваше преди появата на компютрите. С появата им тази нужда стана много осезаема. Сега, през 2019 г., пиша тази статия на лаптоп с 8-ядрен процесор Intel Core, на който паралелно работят повече от сто процеси и дори повече нишки. Наблизо има леко опърпан телефон, купен преди няколко години, има 8-ядрен процесор на борда. Тематичните ресурси са пълни със статии и видеоклипове, в които авторите им се възхищават на тазгодишните водещи смартфони с 16-ядрени процесори. MS Azure предоставя виртуална машина със 20-ядрен процесор и 128 TB RAM за по-малко от $2/час. За съжаление е невъзможно да се извлече максимума и да се използва тази сила, без да можете да управлявате взаимодействието на нишките.

терминология

Процес - OS обект, изолирано адресно пространство, съдържа нишки.
Нишка - OS обект, най-малката единица за изпълнение, част от процес, нишките споделят памет и други ресурси помежду си в рамките на процес.
многозадачност - Собственост на ОС, възможност за стартиране на няколко процеса едновременно
Многоядрен - свойство на процесора, способността да се използват няколко ядра за обработка на данни
Мултипроцесорност - свойство на компютър, способността да работи едновременно с няколко процесора физически
Многопоточност — свойство на процес, способността да се разпределя обработката на данни между няколко нишки.
Паралелизъм - извършване на няколко действия физически едновременно за единица време
Асинхронност — изпълнение на операция без изчакване завършването на тази обработка; резултатът от изпълнението може да бъде обработен по-късно.

метафора

Не всички определения са добри и някои се нуждаят от допълнително обяснение, така че ще добавя метафора за готвенето на закуска към официално въведената терминология. Готвенето на закуска в тази метафора е процес.

Докато приготвях закуската сутрин (процесор) идвам в кухнята (компютър). имам 2 ръце (Цветове). В кухнята има редица устройства (IO): фурна, чайник, тостер, хладилник. Пускам газта, слагам тиган и наливам олио, без да чакам да загрее (асинхронно, Non-Blocking-IO-Wait), вадя яйцата от хладилника и ги счупвам в чиния, след което ги разбивам с една ръка (Тема №1), и второ (Тема №2), държащ табелата (Споделен ресурс). Сега бих искал да включа чайника, но нямам достатъчно ръце (Глад на темата) През това време загрява тигана (Обработвам резултата) в който изсипвам разбитото. Посягам към чайника, включвам го и глупаво гледам как водата кипи в него (Блокиране-IO-Изчакайте), въпреки че през това време можеше да измие чинията, в която разби омлета.

Сготвих омлет само с 2 ръце и нямам повече, но в същото време в момента на разбиване на омлета се случиха 3 операции наведнъж: разбиване на омлета, задържане на чинията, нагряване на тигана , Процесорът е най-бързата част от компютъра, IO е това, което най-често се забавя, така че често ефективно решение е да заемете процесора с нещо, докато получавате данни от IO.

Продължавайки метафората:

• Ако в процеса на приготвяне на омлет бих се опитал да се преоблека, това би било пример за многозадачност. Важен нюанс: компютрите са много по-добри в това от хората.
• Кухня с няколко готвачи, например в ресторант - многоядрен компютър.
• Много ресторанти в заведение за хранене в търговски център - център за данни

.NET инструменти

.NET е добър в работата с нишки, както и с много други неща. С всяка нова версия той въвежда все повече и повече нови инструменти за работа с тях, нови слоеве на абстракция върху OS нишки. Когато работят с изграждането на абстракции, разработчиците на рамка използват подход, който оставя възможността, когато се използва абстракция от високо ниво, да се спусне едно или повече нива по-долу. Най-често това не е необходимо, всъщност отваря вратата да се простреляте в крака с пушка, но понякога, в редки случаи, може да е единственият начин да разрешите проблем, който не е решен на сегашното ниво на абстракция .

Под инструменти имам предвид както интерфейси за програмиране на приложения (API), предоставени от рамката и пакети на трети страни, така и цели софтуерни решения, които опростяват търсенето на всякакви проблеми, свързани с многонишков код.

Стартиране на нишка

Класът Thread е най-основният клас в .NET за работа с нишки. Конструкторът приема един от два делегата:

• ThreadStart — Няма параметри
• ParametrizedThreadStart - с един параметър от тип обект.

Делегатът ще бъде изпълнен в новосъздадената нишка след извикване на метода Start.Ако към конструктора е предаден делегат от тип ParametrizedThreadStart, тогава към метода Start трябва да бъде предаден обект. Този механизъм е необходим за прехвърляне на всяка локална информация към потока. Струва си да се отбележи, че създаването на нишка е скъпа операция, а самата нишка е тежък обект, най-малкото защото разпределя 1MB памет в стека и изисква взаимодействие с OS API.

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

Класът ThreadPool представлява концепцията за пул. В .NET пулът от нишки е част от инженерството и разработчиците от Microsoft са положили много усилия, за да се уверят, че работи оптимално в голямо разнообразие от сценарии.

Обща концепция:

От момента, в който приложението стартира, то създава няколко нишки в резерв във фонов режим и предоставя възможността да ги вземе за използване. Ако нишките се използват често и в голям брой, пулът се разширява, за да отговори на нуждите на повикващия. Когато в пула няма свободни нишки в подходящия момент, той или ще изчака една от нишките да се върне, или ще създаде нова. От това следва, че пулът от нишки е чудесен за някои краткосрочни действия и не е подходящ за операции, които се изпълняват като услуги през цялата работа на приложението.

За да използвате нишка от пула, има метод QueueUserWorkItem, който приема делегат от тип WaitCallback, който има същия подпис като ParametrizedThreadStart и параметърът, подаден към него, изпълнява същата функция.

ThreadPool.QueueUserWorkItem(...);

По-малко известният метод на пула от нишки RegisterWaitForSingleObject се използва за организиране на неблокиращи IO операции. Делегатът, предаван на този метод, ще бъде извикан, когато WaitHandle, предаван на метода, е „Освободен“.

ThreadPool.RegisterWaitForSingleObject(...)

.NET има таймер за нишки и се различава от таймерите на WinForms/WPF по това, че неговият манипулатор ще бъде извикан на нишка, взета от пула.

System.Threading.Timer

Има и доста екзотичен начин за изпращане на делегат за изпълнение към нишка от пула - методът BeginInvoke.

DelegateInstance.BeginInvoke

Бих искал накратко да се спра на функцията, към която могат да бъдат извикани много от горните методи - CreateThread от Kernel32.dll Win32 API. Има начин, благодарение на механизма на външните методи, да извикате тази функция. Виждал съм такова обаждане само веднъж в ужасен пример за наследен код и мотивацията на автора, който е направил точно това, все още остава загадка за мен.

Kernel32.dll CreateThread

Преглед и отстраняване на грешки в нишки

Нишките, създадени от вас, всички компоненти на трети страни и пулът .NET могат да се видят в прозореца Threads на Visual Studio. Този прозорец ще показва информация за нишката само когато приложението е в процес на отстраняване на грешки и в режим на прекъсване. Тук можете удобно да видите имената на стека и приоритетите на всяка нишка и да превключите отстраняването на грешки към конкретна нишка. Използвайки свойството Priority на класа Thread, можете да зададете приоритета на нишката, който OC и CLR ще възприемат като препоръка при разделянето на процесорното време между нишките.

Паралелна библиотека на задачите

Task Parallel Library (TPL) беше въведена в .NET 4.0. Сега това е стандартът и основният инструмент за работа с асинхронност. Всеки код, който използва по-стар подход, се счита за наследен. Основната единица на TPL е класът Task от пространството на имената System.Threading.Tasks. Задачата е абстракция над нишка. С новата версия на езика C# получихме елегантен начин за работа със Tasks - async/await оператори. Тези концепции направиха възможно писането на асинхронен код, сякаш беше прост и синхронен, което направи възможно дори за хора с малко разбиране на вътрешната работа на нишките да пишат приложения, които ги използват, приложения, които не замръзват при извършване на дълги операции. Използването на async/await е тема за една или дори няколко статии, но ще се опитам да разбера същността й в няколко изречения:

• async е модификатор на метод, връщащ Task или void
• а await е неблокиращ оператор за чакаща задача.

Още веднъж: операторът await, в общия случай (има изключения), ще освободи текущата нишка на изпълнение по-нататък и когато Задачата приключи изпълнението си, и нишката (всъщност би било по-правилно да се каже контекстът , но повече за това по-късно) ще продължи да изпълнява метода по-нататък. Вътре в .NET този механизъм се прилага по същия начин като връщането на добива, когато написаният метод се превръща в цял клас, който е машина за състояния и може да се изпълнява на отделни части в зависимост от тези състояния. Всеки, който се интересува, може да напише всеки прост код с помощта на asynс/await, да компилира и прегледа асемблирането с помощта на JetBrains dotPeek с активиран код, генериран от компилатор.

Нека да разгледаме опциите за стартиране и използване на Task. В примера с код по-долу създаваме нова задача, която не прави нищо полезно (Thread.Sleep(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 - Задачите могат да бъдат подредени в йерархия. Ако тази опция е била използвана, тогава задачата може да е в състояние, в което самата тя е завършила и чака изпълнението на своите деца.
• PreferFairness - означава, че би било по-добре да се изпълнят Задачите, изпратени за изпълнение по-рано, преди тези, изпратени по-късно. Но това е само препоръка и резултатите не са гарантирани.

Вторият параметър, предаден на метода, е CancellationToken. За да обработите правилно анулирането на операция, след като е започнала, кодът, който се изпълнява, трябва да бъде изпълнен с проверки за състоянието на CancellationToken. Ако няма проверки, тогава методът Cancel, извикан на обекта CancellationTokenSource, ще може да спре изпълнението на задачата само преди да започне.

Последният параметър е обект на планировчик от тип TaskScheduler. Този клас и неговите наследници са предназначени да контролират стратегии за разпределяне на Задачи между нишки; по подразбиране Задачата ще бъде изпълнена на произволна нишка от пула.

Операторът await се прилага към създадената задача, което означава, че кодът, написан след него, ако има такъв, ще бъде изпълнен в същия контекст (често това означава в същата нишка) като кода преди await.

Методът е маркиран като async void, което означава, че може да използва оператора await, но извикващият код няма да може да изчака изпълнението. Ако такава функция е необходима, тогава методът трябва да върне Task. Методите, маркирани като async void, са доста често срещани: като правило това са манипулатори на събития или други методи, които работят на принципа на пожар и забрава. Ако трябва не само да дадете възможност да изчакате до края на изпълнението, но и да върнете резултата, тогава трябва да използвате Task.

На задачата, която методът StartNew върна, както и на всеки друг, можете да извикате метода ConfigureAwait с false параметъра, след което изпълнението след await ще продължи не върху заснетия контекст, а върху произволен. Това винаги трябва да се прави, когато контекстът на изпълнение не е важен за кода след изчакване. Това също е препоръка от 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
}

В първия пример изчакваме Задачата да завърши, без да блокира извикващата нишка; ще се върнем към обработката на резултата само когато вече е там; дотогава извикващата нишка е оставена на собствените си устройства.

Във втория вариант блокираме извикващата нишка, докато не се изчисли резултатът от метода. Това е лошо не само защото сме заели нишка, толкова ценен ресурс на програмата, с просто бездействие, но и защото ако кодът на метода, който извикваме, съдържа await и контекстът на синхронизация изисква връщане към извикващата нишка след await, тогава ще получим задънена улица: извикващата нишка чака резултатът от асинхронния метод да бъде изчислен, асинхронният метод напразно се опитва да продължи изпълнението си в извикващата нишка.

Друг недостатък на този подход е сложното обработване на грешки. Факт е, че грешките в асинхронния код при използване на async/await са много лесни за обработка - те се държат по същия начин, както ако кодът е синхронен. Въпреки че, ако приложим екзорсизъм на синхронно изчакване към задача, първоначалното изключение се превръща в AggregateException, т.е. За да се справите с изключението, ще трябва да разгледате типа InnerException и да напишете сами if верига вътре в един catch блок или да използвате конструкцията catch when, вместо веригата от catch блокове, която е по-позната в света на C#.

Третият и последен пример също са маркирани като лоши по същата причина и съдържат всички същите проблеми.

Методите WhenAny и WhenAll са изключително удобни за изчакване на група от задачи; те обгръщат група от задачи в една, която ще се задейства или когато задача от групата бъде задействана за първи път, или когато всички те са завършили изпълнението си.

Спиране на нишки

Поради различни причини може да се наложи спиране на потока, след като е започнал. Има няколко начина да направите това. Класът Thread има два метода с подходящи имена: Прекратяване и Прекъсване. Първият силно не се препоръчва за употреба, т.к след извикването му във всеки произволен момент, по време на обработката на всяка инструкция, ще бъде хвърлено изключение ThreadAbortedException. Не очаквате такова изключение да бъде хвърлено при увеличаване на която и да е целочислена променлива, нали? И когато се използва този метод, това е съвсем реална ситуация. Ако трябва да попречите на CLR да генерира такова изключение в определен раздел от кода, можете да го обвиете в извиквания Thread.BeginCriticalRegion, Thread.EndCriticalRegion. Всеки код, написан в блок finally, е обвит в такива извиквания. Поради тази причина в дълбините на кода на рамката можете да намерите блокове с празен опит, но не и празен финал. Microsoft обезсърчава този метод толкова много, че не го включиха в .net core.

Методът Interrupt работи по-предвидимо. Може да прекъсне нишката с изключение ThreadInterruptedException само в онези моменти, когато нишката е в състояние на изчакване. Той влиза в това състояние, докато виси, докато чака WaitHandle, заключване или след извикване на Thread.Sleep.

И двата варианта, описани по-горе, са лоши поради тяхната непредсказуемост. Решението е да се използва структура CancellationToken и класа CancellationTokenSource. Въпросът е следният: създава се екземпляр на класа CancellationTokenSource и само този, който го притежава, може да спре операцията, като извика метода Отказ. Само CancellationToken се предава на самата операция. Собствениците на CancellationToken не могат сами да отменят операцията, а могат само да проверят дали операцията е била отменена. За това има булево свойство IsCancellationRequested и метод ThrowIfCancelRequested. Последното ще хвърли изключение TaskCancelledException ако методът Cancel е бил извикан на екземпляра CancellationToken, който се копира. И това е методът, който препоръчвам да използвате. Това е подобрение в сравнение с предишните опции чрез получаване на пълен контрол върху това в кой момент операцията по изключение може да бъде прекратена.

Най-бруталната опция за спиране на нишка е да се извика функцията TerminateThread на Win32 API. Поведението на CLR след извикване на тази функция може да е непредвидимо. В MSDN е написано следното за тази функция: „TerminateThread е опасна функция, която трябва да се използва само в най-крайните случаи. “

Преобразуване на наследен API в базиран на задачи с помощта на метода FromAsync

Ако имате достатъчно късмет да работите по проект, който е започнат след въвеждането на Tasks и е престанал да предизвиква тих ужас за повечето разработчици, тогава няма да се налага да се справяте с много стари API, както на трети страни, така и на вашия екип е измъчвал в миналото. За щастие екипът на .NET Framework се погрижи за нас, макар че може би целта беше да се погрижим за себе си. Както и да е, .NET разполага с редица инструменти за безболезнено преобразуване на код, написан в стари подходи за асинхронно програмиране, към новия. Един от тях е методът FromAsync на TaskFactory. В примера на кода по-долу обвивам старите асинхронни методи на класа WebRequest в Task, използвайки този метод.

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

Това е само пример и едва ли ще трябва да правите това с вградени типове, но всеки стар проект просто гъмжи от BeginDoSomething методи, които връщат IAsyncResult и EndDoSomething методи, които го получават.

Преобразувайте наследения API в базиран на задачи с помощта на класа TaskCompletionSource

Друг важен инструмент, който трябва да имате предвид, е класът TaskCompletionSource. От гледна точка на функциите, предназначението и принципа на работа, той може да напомня донякъде на метода RegisterWaitForSingleObject на класа ThreadPool, за който писах по-горе. Използвайки този клас, можете лесно и удобно да опаковате стари асинхронни API в Задачи.

Ще кажете, че вече говорих за метода FromAsync на класа TaskFactory, предназначен за тези цели. Тук ще трябва да си припомним цялата история на разработването на асинхронни модели в .net, които Microsoft предложи през последните 15 години: преди Task-Based Asynchronous Pattern (TAP), имаше Asynchronous Programming Pattern (APP), който беше за методи ЗапочнетеНаправете нещо, което се връща IAsyncResult и методи КрайDoSomething, който го приема и за наследството от тези години, методът FromAsync е просто перфектен, но с течение на времето той беше заменен от базирания на събития асинхронен модел (EAP), което предполага, че ще бъде предизвикано събитие, когато асинхронната операция завърши.

TaskCompletionSource е идеален за обвиване на Tasks и наследени API, изградени около модела на събитието. Същността на неговата работа е следната: обект от този клас има публично свойство от тип Task, чието състояние може да се контролира чрез методите SetResult, SetException и др. на класа TaskCompletionSource. На места, където операторът за изчакване е приложен към тази задача, тя ще бъде изпълнена или неуспешна с изключение в зависимост от метода, приложен към TaskCompletionSource. Ако все още не е ясно, нека да разгледаме този пример с код, където някакъв стар EAP API е обвит в задача с помощта на TaskCompletionSource: когато събитието се задейства, задачата ще бъде прехвърлена в състояние Completed и методът, който е приложил оператора await към тази Задача ще възобнови изпълнението си след получаване на обекта резултат.

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 не е всичко, което може да се направи с помощта на TaskCompletionSource. Използването на този клас отваря интересна възможност за проектиране на различни API за задачи, които не заемат нишки. А потокът, както си спомняме, е скъп ресурс и техният брой е ограничен (главно от размера на RAM). Това ограничение може лесно да бъде постигнато чрез разработване, например, на заредено уеб приложение със сложна бизнес логика. Нека разгледаме възможностите, за които говоря, когато прилагаме такъв трик като Long-Polling.

Накратко, същността на трика е следната: трябва да получите информация от API за някои събития, случващи се от негова страна, докато API по някаква причина не може да докладва събитието, а може само да върне състоянието. Пример за това са всички API, изградени върху HTTP преди времето на WebSocket или когато е било невъзможно по някаква причина да се използва тази технология. Клиентът може да попита 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, подобно на оператора yield return, генерират state machine от метода и това е създаването на нов обект, което почти винаги не е важно, но в редки случаи може да създаде проблем. Този случай може да е метод, който се извиква наистина често, говорим за десетки и стотици хиляди обаждания в секунда. Ако такъв метод е написан по такъв начин, че в повечето случаи връща резултат, заобикаляйки всички чакащи методи, тогава .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));
}

Нека разгледаме по-отблизо тази част от кода: ако има стойност в кеша, ние създаваме структура, в противен случай истинската задача ще бъде обвита в смислена. Извикващият код не се интересува в кой път е бил изпълнен този код: ValueTask, от гледна точка на синтаксиса на C#, ще се държи по същия начин като обикновена задача в този случай.

TaskSchedulers: управление на стратегии за стартиране на задачи

Следващият API, който бих искал да разгледам, е класът Task Scheduler и неговите производни. Вече споменах по-горе, че TPL има способността да управлява стратегии за разпределяне на задачи в нишки. Такива стратегии са дефинирани в наследниците на класа TaskScheduler. Почти всяка стратегия, от която може да се нуждаете, може да бъде намерена в библиотеката. ParallelExtensionsExtras, разработен от Microsoft, но не е част от .NET, а се доставя като пакет Nuget. Нека разгледаме накратко някои от тях:

• CurrentThreadTaskScheduler — изпълнява задачи в текущата нишка
• LimitedConcurrencyLevelTaskScheduler — ограничава броя на задачите, изпълнявани едновременно чрез параметър N, който се приема в конструктора
• OrderedTaskScheduler — се дефинира като LimitedConcurrencyLevelTaskScheduler(1), така че задачите ще се изпълняват последователно.
• WorkStealingTaskScheduler - инструменти кражба на работа подход към разпределението на задачите. По същество това е отделен ThreadPool. Решава проблема, че в .NET ThreadPool е статичен клас, един за всички приложения, което означава, че претоварването му или неправилното му използване в една част на програмата може да доведе до странични ефекти в друга. Освен това е изключително трудно да се разбере причината за такива дефекти. Че. Може да има нужда от използване на отделни WorkStealingTaskSchedulers в части от програмата, където използването на ThreadPool може да бъде агресивно и непредвидимо.
• QueuedTaskScheduler — ви позволява да изпълнявате задачи според правилата за приоритетна опашка
• ThreadPerTaskScheduler — създава отделна нишка за всяка задача, която се изпълнява върху нея. Може да бъде полезно за задачи, чието изпълнение отнема непредсказуемо дълго време.

Има добър детайл статия относно TaskSchedulers в блога на Microsoft.

За удобно отстраняване на грешки на всичко, свързано със Задачи, Visual Studio има прозорец Задачи. В този прозорец можете да видите текущото състояние на задачата и да преминете към текущо изпълнявания ред от код.

PLinq и паралелният клас

В допълнение към Tasks и всичко казано за тях, в .NET има още два интересни инструмента: PLinq (Linq2Parallel) и класа Parallel. Първият обещава паралелно изпълнение на всички Linq операции на множество нишки. Броят на нишките може да бъде конфигуриран с помощта на метода на разширение WithDegreeOfParalleism. За съжаление най-често PLinq в режима си по подразбиране няма достатъчно информация за вътрешността на вашия източник на данни, за да осигури значително увеличение на скоростта, от друга страна, цената на опита е много ниска: просто трябва да извикате метода AsParallel преди веригата от методи на Linq и изпълнете тестове за ефективност. Освен това е възможно да прехвърлите допълнителна информация към PLinq относно естеството на вашия източник на данни, като използвате механизма за дялове. Можете да прочетете повече тук и тук.

Статичният клас Parallel предоставя методи за итерация през колекция Foreach паралелно, изпълнение на For цикъл и изпълнение на множество делегати в паралелно извикване. Изпълнението на текущата нишка ще бъде спряно, докато изчисленията не приключат. Броят на нишките може да бъде конфигуриран чрез предаване на ParallelOptions като последен аргумент. Можете също да посочите TaskScheduler и CancellationToken, като използвате опции.

Данни

Когато започнах да пиша тази статия въз основа на материалите от моя доклад и информацията, която събрах по време на работата си след него, не очаквах, че ще има толкова много. Сега, когато текстовият редактор, в който пиша тази статия, ми каже укорително, че страница 15 е изчезнала, ще обобщя междинните резултати. Други трикове, API, визуални инструменти и клопки ще бъдат разгледани в следващата статия.

Изводи:

• Трябва да знаете инструментите за работа с нишки, асинхронност и паралелизъм, за да използвате ресурсите на съвременните компютри.
• .NET има много различни инструменти за тези цели
• Не всички от тях се появиха наведнъж, така че често можете да намерите наследени, но има начини да конвертирате стари API без много усилия.
• Работата с нишки в .NET е представена от класовете Thread и ThreadPool
• Методите Thread.Abort, Thread.Interrupt и Win32 API TerminateThread са опасни и не се препоръчват за използване. Вместо това е по-добре да използвате механизма CancellationToken
• Потокът е ценен ресурс и предлагането му е ограничено. Трябва да се избягват ситуации, при които нишките са заети в очакване на събития. За това е удобно да използвате класа TaskCompletionSource
• Най-мощните и усъвършенствани .NET инструменти за работа с паралелизъм и асинхронност са Tasks.
• C# async/await операторите реализират концепцията за неблокиращо изчакване
• Можете да контролирате разпределението на задачите между нишките, като използвате класове, извлечени от TaskScheduler
• Структурата ValueTask може да бъде полезна за оптимизиране на горещи пътища и трафик на паметта
• Прозорците за задачи и нишки на Visual Studio предоставят много полезна информация за отстраняване на грешки в многонишков или асинхронен код
• PLinq е страхотен инструмент, но може да няма достатъчно информация за вашия източник на данни, но това може да се поправи с помощта на механизма за разделяне
• За да се продължи ...

Източник: www.habr.com