.NET: Verktyg för arbete med multitrådning och asynkronitet. Del 1

Jag publicerar på Habr originalartikeln vars översättning finns i företaget blogg.

Behovet av att göra något asynkront, utan att vänta på resultat här och nu, eller att dela upp ett stort arbete mellan flera enheter som utför det, har funnits även innan datorernas tid. Med deras ankomst blev detta behov mycket tydligt. Nu, 2019, medan jag skriver denna artikel på en bärbar dator med en 8-kärnig Intel Core-processor, vilket samtidigt hanterar hundratals processer, var och en med ännu fler trådar. Bredvid ligger en något sliten mobiltelefon jag köpte för ett par år sedan, som har en 8-kärnig processor. Det finns gott om artiklar och videor på specialiserade resurser där författarna beundrar de flaggskepps-smartphones som har 16-kärniga processorer i år. MS Azure erbjuder en virtuella maskin med en 128-kärnig processor och 2 TB RAM för mindre än 20 $/timme. Tyvärr är det omöjligt att utnyttja den maximala kraften och tygla denna kraft utan att kunna hantera interaktionen mellan trådarna.

Terminologi

Process — ett OS-objekt, ett isolerat adressutrymme som innehåller trådar.
Tråd — ett OS-objekt, den minsta enheten för utförande, en del av processen, trådar delar minne och andra resurser sinsemellan inom processen.
Multitasking — en egenskap hos operativsystemet, möjligheten att utföra flera processer samtidigt
Flerkärnighet — en egenskap hos processorn, möjligheten att använda flera kärnor för databehandling
Flermaskinvaruarkitektur — en egenskap hos datorn, möjligheten att arbeta med flera processorer fysiskt samtidigt
Multitrådning — en egenskap hos processen, möjligheten att fördela databehandling mellan flera trådar.
Parallellitet — utförande av flera åtgärder fysiskt samtidigt under en viss tidsenhet
Asynkronitet — utförande av en operation utan att vänta på att fullföra denna behandling, resultatet kan bearbetas senare.

Metafor

Inte alla definitioner är bra, och några behöver ytterligare förklaring, så jag lägger till en metafor om att laga frukost till den formella terminologin. Laga frukost i denna metafor är processen.

Medan jag lagar frukost på morgonen kommer jag (CPU) in i köket (Datorn). Jag har två händer (Kärnor). I köket finns flera apparater (IO): ugn, vattenkokare, brödrost, kylskåp. Jag slår på gasen, ställer en stekpanna på och häller i olja, utan att vänta på att den ska värmas upp (asynkront, Non-Blocking-IO-Wait), tar jag ut äggen från kylskåpet och slår dem i en tallrik, varpå jag vispar med ena handen (Tråd#1), och med den andra (Tråd#2) håller jag tallriken (Delad Resurs). Just nu skulle jag också vilja sätta på vattenkokaren, men jag har inte tillräckligt med händer (Trådsvält) Under tiden värms stekpannan (Resultatbearbetning) dit jag häller det jag har vispat. Jag sträcker mig till vattenkokaren och sätter på den och ser bara på medan vattnet kokar (Blocking-IO-Wait), även om jag skulle kunnat diska tallriken där jag vispade omeletten under den tiden.

Jag lagade omelett med endast två händer, och fler har jag inte, men vid tillagningen av omeletten pågick samtidigt tre operationer: vispning av omelett, hålla tallriken, värma stekpannan. CPU är den snabbaste delen av datorn, IO är det som oftast bromsar, och därför är en effektiv lösning ofta att sysselsätta CPU:n medan data hämtas från IO.

För att fortsätta metaforen:

• Om jag under tillagningen av omeletten också försökte byta kläder skulle det vara ett exempel på multitasking. En viktig detalj: datorer klarar detta mycket bättre än människor.
• Köket med flera kockar, som i en restaurang – en flerkärnig dator.
• Många restauranger på en matmarknad i ett köpcentrum – ett datacenter

Verktyg .NET

I arbetet med trådar, liksom i mycket annat, är .NET bra. Med varje ny version introducerar den fler och fler nya verktyg för att arbeta med dem, nya abstraktionslager ovanpå operativsystemets trådar. Vid konstruktion av abstraktioner använder ramverksutvecklarna en metod som ger möjlighet att, när högre abstraktion används, gå ner ett eller flera nivåer. Oftast finns det inget behov av detta, dessutom öppnar det möjligheten för att skjuta sig själv i foten med en hagelgevär, men ibland, i sällsynta fall, kan det vara det enda sättet att lösa ett problem som inte kan lösas på den aktuella abstraktionsnivån.

Med verktygen menar jag både programmeringsgränssnitt (API) som tillhandahålls av ramverket och tredjepartsbibliotek samt hela programlösningar som förenklar identifiering av eventuella problem relaterade till flertrådig kod.

Starta tråd

Klassen Thread, den mest grundläggande i .NET för att arbeta med trådar. Den tar ett av två delegattyper i konstruktorn:

• ThreadStart — Utan parametrar
• ParametrizedThreadStart — med en parameter av typen object.

Delegaten kommer att köras i den ny skapade tråden efter att metoden Start har anropats; om en parametriserad delegat skickas till konstruktorn, måste ett objekt överföras till metoden Start. Denna mekanism behövs för att överföra lokal information till tråden. Det är värt att notera att skapandet av en tråd är en kostsam operation, och själva tråden är ett tungt objekt, framför allt eftersom 1 MB minne allokeras för stacken och det kräver interaktion med operativsystemets API.

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

Klassen ThreadPool representerar konceptet av en pool. I .NET är trådpoolen ett ingenjörskonstverk och utvecklarna på Microsoft har investerat mycket tid och ansträngning för att den ska fungera optimalt i olika scenarier.

Allmän koncept:

Från det ögonblick applikationen startar skapas flera reservtrådar i bakgrunden och möjliggör att använda dem. Om trådarna används ofta och i stor mängd, så expanderar poolen för att tillfredsställa behovet hos den anropande koden. När det i poolen vid ett givet tillfälle inte finns några lediga trådar, antingen väntar den på att en tråd ska återvända, eller så skapas en ny. Detta innebär att trådpoolen är utmärkt för korta uppgifter men inte lämpad för operationer som fungerar som tjänster under hela applikationens livslängd.

För att använda en tråd från poolen finns det metoden QueueUserWorkItem, som tar en delegat av typen WaitCallback, vilken har samma signatur som ParametrizedThreadStart, och parametern som skickas till den utför samma funktion.

ThreadPool.QueueUserWorkItem(...);

En mindre känd metod i trådpoolen, RegisterWaitForSingleObject, används för att hantera icke-blockerande IO-operationer. Delegaten som skickas till denna metod kommer att anropas när WaitHandle som skickas till metoden 'släpps' (Released).

ThreadPool.RegisterWaitForSingleObject(...)

I .NET finns det en tråd-timer och den skiljer sig från WinForms/WPF-timrar genom att dess hanterare kommer att anropas i en tråd som tas från poolen.

System.Threading.Timer

Det finns också ett ganska exotiskt sätt att skicka en delegat för körning i en tråd från poolen — metoden BeginInvoke.

DelegateInstance.BeginInvoke

Jag vill kort beröra funktionen som många av de ovan nämnda metoderna handlar om — CreateThread från Kernel32.dll Win32 API. Det finns ett sätt att anropa denna funktion tack vare mekanismen för extern metoder. Jag har bara sett ett sådant anrop en gång i en skrämmande gammal legacy-kod, och motivet bakom författarens val förblir en gåta för mig.

Kernel32.dll CreateThread

Granska och debugga trådar

De trådar som du personligen har skapat, alla tredjeparts-komponenter och .NET-trådar kan visas i fönstret Trådar i Visual Studio. Detta fönster visar information om trådarna endast när applikationen är i debug-läge och stannad (Break mode). Här kan du enkelt se stackarna, namnen och prioriteringarna för varje tråd, och skifta debug-läget till en specifik tråd. Trådklassens egenskap Priority kan ställas in för att ange en rekommendation om trådens prioritet som OS och CLR ska beakta vid fördelning av processor-tid mellan trådarna.

Task Parallel Library

Task Parallel Library (TPL) introducerades i .NET 4.0. Det är nu standarden och det huvudsakliga verktyget för arbete med asynkronitet. All kod som använder äldre metodik betraktas som legacy. TPL:s grundläggande enhet är klassen Task från namespaces System.Threading.Tasks. Task representerar en abstraktion över en tråd. Med den nya versionen av C# fick vi ett elegant sätt att arbeta med Tasks — async/await-operatörer. Dessa koncept gjorde det möjligt att skriva asynkron kod som om den vore enkel och synkron, vilket gjorde det möjligt även för dem som har begränsad förståelse för trådarnas inre funktioner att skriva applikationer som använder dem, utan att applikationerna fryser under långvariga operationer. Användning av async/await är ett ämne för en eller flera artiklar, men jag ska försöka sammanfatta essensen i några meningar:

• async är en modifikator för metoder som returnerar Task eller void
• och await är en operator för icke-blockerande väntan på en Task.

Återigen: await-operatören, i allmänhet (det finns undantag), kommer att släppa det nuvarande utförandeflödet vidare, och när Task är klar med sin körning, kommer flödet (det är faktiskt mer korrekt att säga kontext, men mer om detta senare) att fortsätta utförandet av metoden. Inom .NET är denna mekanism implementerad på samma sätt som yield return, när en skriven metod omvandlas till en hel klass, som är en tillståndsmaskin och kan köras i separata bitar beroende på dessa tillstånd. De som är intresserade kan skriva någon enkel kod med användning av async/await, kompilera den och se samlingen med hjälp av JetBrains dotPeek med aktiverad Compiler Generated Code.

Låt oss titta på alternativ för att starta och använda Task. I exemplet nedan skapar vi en ny task som inte gör något användbart (Thread.Sleep(10000)), men i verkliga livet bör detta vara något komplext som involverar CPU-arbete.

using TCO = System.Threading.Tasks.TaskCreationOptions;

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

    await Task.Factory.StartNew(
        // Koden för åtgärden kommer att köras i en annan kontext
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    // Koden efter await kommer att köras i fångad kontext
}

Task skapas med ett antal alternativ:

• LongRunning — en hint om att uppgiften inte kommer att slutföras snabbt, och det kan vara värt att överväga att inte ta en tråd från poolen, utan att skapa en separat för denna Task för att inte skada de andra.
• AttachedToParent — Tasks kan ordnas i hierarkier. Om detta alternativ har använts kan Task befinna sig i ett tillstånd där den själv har slutförts och väntar på att dottern ska slutföras.
• PreferFairness — innebär att det vore bra att köra Tasks som skickades för utförande tidigare innan de som skickades senare. Men detta är bara en rekommendation och resultatet är inte garanterat.

Det andra parametern i metoden är en CancellationToken. För korrekt hantering av avbrytning av operationen efter dess start måste den körda koden vara fylld med kontroller för tillståndet av CancellationToken. Om det inte finns några kontroller kan metoden Cancel som anropas på objektet CancellationTokenSource stoppa körningen av Task-en bara före dess start.

Den sista parametern är ett objekt av typen TaskScheduler. Denna klass och dess derviat betjänar för att hantera strategier för fördelning av Tasks över trådar, som standard kommer Task att köras på en slumpmässig tråd från poolen.

Det skapade Task har en await-operator tillämpad, vilket innebär att koden som skrivs efter det, om sådan finns, kommer att köras i samma kontext (detta betyder ofta att den körs på samma tråd) som koden före await.

Metoden är markerad som async void, vilket innebär att det är tillåtet att använda await-operatorn i den, men den som anropar koden kan inte vänta på att den ska avslutas. Om ett sådant behov finns bör metoden returnera en Task. Metoder markerade som async void förekommer ganska ofta: vanligtvis är de händelsehanterare eller andra metoder som fungerar enligt principen kör och glöm (fire and forget). Om det är nödvändigt att både kunna vänta på att körningen ska avslutas och returnera ett resultat, bör Task användas.

På Task som returnerades av metoden StartNew, precis som på vilken annan som helst, kan metoden ConfigureAwait med parameter false anropas, då fortsätter körningen efter await inte i den fångade kontexten utan på en godtycklig sådan. Detta bör alltid göras när kontexten för koden efter await inte är avgörande. Detta är också en rekommendation från MS när man skriver kod som kommer att levereras i ett paketerat biblioteksformat.

Låt oss stanna upp lite mer vid hur vi kan vänta på att en Task ska avslutas. Nedan är ett kodexempel med kommentarer, där väntan görs förhållandevis bra och när det görs förhållandevis dåligt.

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // bra

    result = AsyncMethod().Result; // dåligt

    AsyncMethod().Wait(); // dåligt

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

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

    Task.WaitAll(tasks.ToArray()); // dåligt
}

I det första exemplet väntar vi på att Task ska avslutas utan att blockera den anropande tråden, vi kommer tillbaka till att bearbeta resultatet först när det är klart, tills dess är den anropande tråden fri.

I det andra fallet blockerar vi den anropande tråden tills resultatet av metoden har beräknats. Detta är dåligt inte bara för att vi har blockerat en tråd, en så värdefull resurs i programmet, med simpel sysslolöshet, utan också för att om det finns await i metoden vi anropar, och synkroniseringskontexten förväntar sig att återgå till den anropande tråden efter await, så får vi en deadlock: den anropande tråden väntar på att resultatet av den asynkrona metoden ska beräknas medan den asynkrona metoden förgäves försöker fortsätta sin exekvering i den anropande tråden.

En annan nackdel med detta tillvägagångssätt är den komplicerade felhanteringen. Grejen är att hantera fel i asynkron kod med hjälp av async/await är mycket lätt — de beter sig som om koden vore synkron. Medan om vi använder synkront väntande på en Task, så kapslas det ursprungliga undantaget in i AggregateException, vilket innebär att vi måste undersöka typen av InnerException och själva skriva en kedja av if-satser inom en catch-block eller använda konstruktionen catch when, istället för den mer vanliga kedjan av catch-block i C#-världen.

Det tredje och sista exemplet har också märkts för att vara dåligt av samma anledning och innehåller alla samma problem.

Metoderna WhenAny och WhenAll är extremt användbara för att vänta på en grupp av Tasks, de kapslar in en grupp av Tasks i en som kommer att aktiveras antingen vid den första av gruppens Tasks eller när alla har avslutat sin exekvering.

Stoppa trådar

Av olika skäl kan det uppstå ett behov att stoppa en tråd efter att den har startat. Det finns flera sätt att göra detta. Klassen Thread har två metoder med passande namn — det är Avbryt och Interrupt. Den första rekommenderas starkt att inte använda, eftersom det efter anropet kan kastas ett undantag när som helst under utförandet av valfri instruktion. ThreadAbortedException. Du förväntar dig inte att ett sådant undantag ska uppstå vid inkrementering av en heltalsvariabel, eller hur? Men med denna metod är det en helt realitet. Om det är nödvändigt att förbjuda CLR från att generera sådant undantag i ett visst kodavsnitt kan det omges av anrop till Thread.BeginCriticalRegion, Thread.EndCriticalRegion. Sådana åtgärder omger all kod som skrivits i finally-blocket. Av den anledningen kan det i ramverkets kodbas finnas block med tomma try, men inte tomma finally. Microsoft rekommenderar så starkt att använda denna metod att de inte har inkluderat den i .net core.

Metoden Interrupt fungerar mer förutsägbart. Den kan avbryta en tråd med ett undantag ThreadInterruptedException endast i de ögonblick då tråden befinner sig i vänteläge. Den når detta tillstånd genom att hänga på ett WaitHandle, lock eller efter att ha anropat Thread.Sleep.

Båda de ovanstående alternativen är dåliga på grund av sin oförutsägbarhet. Lösningen är att använda strukturen CancellationToken och klassen CancellationTokenSource. Poängen är följande: en instans av klassen CancellationTokenSource skapas och endast den som äger den kan stoppa operationen genom att kalla metoden Cancel. I själva operationen skickas endast CancellationToken. Ägare av CancellationToken kan inte själva avbryta operationen, de kan endast kontrollera om operationen har avbrutits. För detta finns en boolesk egenskap IsCancellationRequested och metoden ThrowIfCancelRequested. Den sistnämnda kommer att generera ett undantag TaskCancelledException om metoden Cancel har anropats på den medföljande CancellationToken-exemplaret av CancellationTokenSource. Och det är just denna metod jag rekommenderar att använda. Det ger bättre kontroll över när undantagsoperationen kan avbrytas.

Det mest drastiska sättet att stoppa en tråd är att anropa Win32 API-funktionen TerminateThread. CLR:s beteende efter att denna funktion har anropats kan vara oförutsägbart. På MSDN står följande om denna funktion: “TerminateThread is a dangerous function that should only be used in the most extreme cases.”

Konvertering av legacy-API till taskbaserat med metoden FromAsync

Om du har turen att arbeta på ett projekt som startades efter att uppgifterna infördes och som slutade att orsaka tyst skräck hos de flesta utvecklare, så behöver du inte hantera många gamla API:er, vare sig tredjeparts eller de som ditt team har skapat tidigare. Som tur är har .NET Frameworks utvecklingsteam tagit hand om oss, även om syftet möjligen var att ta hand om sig själva. Hur som helst finns det i .NET en rad verktyg för smärtfri konvertering av kod skrivna i gamla tillvägagångssätt för asynkron programmering till nya. En av dem är metoden FromAsync i TaskFactory. I koden nedan kapslar jag in gamla asynkrona metoder från klassen WebRequest i en Task med hjälp av denna metod.

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

Detta är bara ett exempel och du kommer knappast behöva göra detta med inbyggda typer, men vilket gammalt projekt som helst är fullt av metoder som BeginDoSomething som returnerar IAsyncResult och metoder som EndDoSomething som tar emot det.

Konvertering av legacy-API:er till Task Based med hjälp av klassen TaskCompletionSource

Ett annat viktigt verktyg att överväga är klassen TaskCompletionSource. I funktioner, syfte och arbetsprincip kan den påminna om metoden RegisterWaitForSingleObject i klassen ThreadPool som jag nämnde ovan. Med hjälp av denna klass kan du enkelt och bekvämt kapsla in gamla asynkrona API:er i Tasks.

Du kanske säger att jag redan har pratat om metoden FromAsync i klassen TaskFactory som är avsedd för dessa syften. Här måste vi återkalla hela historien om utvecklingen av asynkrona modeller i .NET som Microsoft har erbjudit under de senaste 15 åren: innan Task-Based Asynchronous Pattern (TAP) fanns det Asynchronous Programming Pattern (APP), vilket handlade om metoderna BeginDoSomething som returnerar IAsyncResult och metoderna EndDoSomething som tar emot det och för legacy från dessa år passar metoden FromAsync utmärkt, men med tiden kom Event Based Asynchronous Pattern (EAP), vilket antog att ett evenemang skulle utlösas när den asynkrona operationen var slutförd.

TaskCompletionSource är perfekt för att kapsla in Task:er från legacy-API:er som bygger på en händelsestyrd modell. Kärnan i dess funktion är följande: objektet av denna klass har en offentlig egenskap av typen Task vars tillstånd kan styras via metoderna SetResult, SetException och så vidare. Klassen TaskCompletionSource. I de ställen där await-operatorn har använts på denna Task kommer den att fullföljas eller krascha med ett undantag beroende på vilken metod som tillämpades på TaskCompletionSource. Om det fortfarande är oklart, låt oss titta på detta kodexempel där ett gammalt API från EAP-kontrolleras i Task med hjälp av TaskCompletionSource: när en händelse inträffar kommer Task att ledas till tillståndet Completed, och metoden som tillämpar await-operatorn på denna Task kommer att återuppta sitt utförande och få objektet. result.

public static Task DoAsync(this SomeApiInstance someApiObj) {

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

    return completionSource.Task;
}

TaskCompletionSource Tips & Tricks

Kapsla gamla API:er är inte allt som kan göras med TaskCompletionSource. Användningen av denna klass öppnar intressanta möjligheter för att designa olika API:er baserade på Task:er, vilket inte blockerar trådar. Och en tråd, som vi minns, är en dyr resurs och antalet av dem är begränsat (främst av RAM-mängden). Detta begränsning är lätt att nå när man utvecklar, till exempel, en tung webbapplikation med komplex affärslogik. Låt oss titta på de möjligheter jag talar om genom att implementera ett sådant trick som Long-Polling.

Kort sagt handlar tricket om att få information från ett API om vissa händelser som sker på dess sida, medan API:t av olika skäl inte kan rapportera om händelsen, utan bara returnera sitt tillstånd. Exempel på detta är alla API:er som byggdes ovanpå HTTP innan WebSocket-tiden eller när teknologin inte kan användas av någon anledning. Klienten kan fråga HTTP-servern. HTTP-servern kan inte själv initiera kommunikation med klienten. En enkel lösning är att poll servern med en timer, men det skapar ytterligare belastning på servern och en genomsnittlig fördröjning på TimerInterval / 2. För att kringgå detta uppfanns tricket som kallas Long Polling, vilket innebär att svaret från servern fördröjs tills timeouten går ut eller en händelse inträffar. Om en händelse inträffar behandlas den, om inte, skickas förfrågan om igen.

while(!eventOccures && !timeoutExceeded)  {

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

Men en sådan lösning kommer att prestera katastrofalt så snart antalet klienter som väntar på händelsen ökar, eftersom varje sådan klient i väntan på händelsen tar upp en hel tråd. Dessutom får vi en extra fördröjning på 1 ms vid händelseutlösning, vilket oftast inte är avgörande, men varför göra mjukvaran sämre än den kan vara? Om vi tar bort Thread.Sleep(1), så belastar vi onödigt ett CPU-kärna till 100% i en meningslös loop. Med hjälp av TaskCompletionSource kan vi enkelt omarbeta denna kod och lösa alla tidigare nämnda problem:

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource> tasks;

    public async Task AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource();
        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);
    }
}

Denna kod är inte produktionsklar, utan är bara för demonstrationsändamål. För att använda den i verkliga scenarier måste man minst hantera situationen när ett meddelande kom i ett ögonblick när ingen förväntade sig det: i det fallet bör metoden AcceptMessageAsync returnera en redan slutförd Task. Om detta fall är det vanligaste, kan man även överväga att använda ValueTask.

Vid mottagandet av en förfrågan om ett meddelande skapar vi och placerar i ordboken TaskCompletionSource, och sedan väntar vi på vad som sker först: den angivna tidsintervallet går ut eller ett meddelande tas emot.

ValueTask: varför och hur

Operatörerna async/await, liksom operatorn yield return, genererar en tillståndsmaskin från metoden, vilket innebär att ett nytt objekt skapas. Detta är nästan alltid oviktigt, men i sällsynta fall kan det skapa problem. Detta kan hända om metoden kallas mycket frekvent, som tiotusentals eller hundratusentals gånger per sekund. Om en sådan metod är skriven så att den i de flesta fall returnerar ett resultat utan att passera alla await-metoder, så tillhandahåller .NET ett verktyg för att optimera detta – strukturen ValueTask. För att förstå detta, låt oss titta på ett exempel på dess användning: det finns en cache som vi ofta går till. Vissa värden finns där och vi returnerar dem bara, om de inte finns, går vi till något långsamt IO för att hämta dem. Det senare vill vi göra asynkront, vilket innebär att hela metoden blir asynkron. Således är den uppenbara varianten av metoden följande:

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

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

På grund av önskan att optimera lite och en lätt rädsla för vad Roslyn kommer att generera när den kompilerar denna kod, kan detta exempel skrivas om på följande sätt:

public Task<string> GetById(int id) {

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

Det verkligt optimala lösningen i detta fall skulle vara att optimera hot-path, nämligen att hämta värdet från ordboken utan onödiga allokeringar och belastning på GC, medan i de sällsynta fall vi faktiskt behöver gå till IO för data, allt förblir plus/minus som tidigare:

public ValueTask<string> GetById(int id) {

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

Låt oss titta närmare på detta kodfragment: när det finns ett värde i cachen skapar vi en struktur, annars kommer den verkliga uppgiften att vara insvept i en signifikant. Den anropande koden bryr sig inte om vilket sätt denna kod har körts: ValueTask kommer ur C#-syntaxens synvinkel att bete sig på samma sätt som en vanlig Task i detta fall.

TaskScheduler: hantera strategier för körning av uppgifter

Det nästa API som vi skulle vilja granska är klassen TaskScheduler och dess derivat. Jag nämnde tidigare att det finns möjlighet att hantera strategier för distribution av uppgifter över trådar i TPL. Sådana strategier definieras i underklasser av TaskScheduler. Nästan vilken strategi som helst som kan behövas kommer att hittas i biblioteket. ParallelExtensionsExtras, utvecklad av Microsoft, men som inte är en del av .NET, utan levereras som ett NuGet-paket. Låt oss korttitta på några av dem:

• CurrentThreadTaskScheduler — kör uppgifter på den aktuella tråden.
• LimitedConcurrencyLevelTaskScheduler — begränsar antalet uppgifter som körs samtidigt med parameter N, vilket tas emot i konstruktorn.
• OrderedTaskScheduler — definieras som LimitedConcurrencyLevelTaskScheduler(1), vilket innebär att uppgifterna kommer att köras sekventiellt.
• WorkStealingTaskScheduler — implementerar work-stealing metoden för uppgiftsdistribution. Den utgör i grunden en separat ThreadPool. Löser problemet att .NET ThreadPool är en statisk klass, en för alla applikationer, vilket innebär att överbelastning eller felaktig användning i en del av programmet kan leda till bieffekter i en annan del. Dessutom är det mycket svårt att förstå orsaken till sådana defekter. Det kan därför finnas ett behov av att använda separata WorkStealingTaskScheduler i de delar av programmet där användningen av ThreadPool kan vara aggressiv och oförutsägbar.
• QueuedTaskScheduler — möjliggör att köra uppgifter enligt prioritetsköregler.
• ThreadPerTaskScheduler — skapar en separat tråd för varje uppgift som körs på den. Kan vara användbart för uppgifter som tar oförutsägbart lång tid.

Det finns en bra detaljerad artikeln om TaskScheduler i Microsofts blogg.

För bekväm felsökning av allt relaterat till uppgifter i Visual Studio finns det ett fönster för Uppgifter. I detta fönster kan du se det aktuella tillståndet för en uppgift och gå till den kodrad som för närvarande körs.

PLinq och klassen Parallel

Förutom Tasks och allt som har sagts om .NET finns det ytterligare två intressanta verktyg: PLinq (Linq2Parallel) och klassen Parallel. Den första lovar parallell exekvering av alla Linq-operationer på flera trådar. Antalet trådar kan konfigureras med metoden WithDegreeOfParallelism. Tyvärr räcker PLinq i standardläge oftast inte med information om innehållet i din datakälla för att ge betydande hastighetsvinster, å andra sidan är kostnaden för att försöka mycket låg: du behöver bara kalla metoden AsParallel före kedjan av Linq-metoder och utföra prestanda tester. Dessutom finns det möjlighet att skicka ytterligare information om din datakälla till PLinq via mekanismen Partitions. Mer information kan läsas här och här.

Den statiska klassen Parallel tillhandahåller metoder för parallell genomgång av en samling med Foreach, utförande av en For-slinga och körning av flera delegater i parallell Invoke. Den aktuella tråden kommer att stoppas tills beräkningarna är klara. Antalet trådar kan konfigureras genom att skicka ParallelOptions som sista argument. Med hjälp av alternativ kan du också ange TaskScheduler och CancellationToken.

Slutsatser

När jag började skriva denna artikel baserat på material från min presentation och information som jag samlat under min tid efteråt, förväntade jag mig inte att det skulle bli så mycket. Nu när textredigeraren där jag skriver denna artikel med ett klanderande meddelande säger att jag är på sida 15, sammanfattar jag de föregående punkterna. Andra tricks, API:er, visuella verktyg och fallgropar kommer att diskuteras i nästa artikel.

Slutsatser:

• Det är viktigt att känna till verktygen för att arbeta med trådar, asynkronitet och parallellism för att kunna använda resurserna på moderna datorer.
• .NET har många olika verktyg för dessa ändamål
• Inte alla dök upp på en gång, så det är ofta möjligt att träffa på legacy, men det finns sätt att konvertera gamla API:er utan större ansträngning.
• Arbete med trådar i .NET representeras av klasserna Thread och ThreadPool
• Metoderna Thread.Abort, Thread.Interrupt och Win32 API-funktionen TerminateThread är farliga och rekommenderas inte att använda. Istället är det bättre att använda mekanismen med CancellationTokens.
• Flöden är en värdefull resurs och deras antal är begränsat. Det är viktigt att undvika situationer där flödena är upptagna med att vänta på händelser. För detta ändamål är det praktiskt att använda klassen TaskCompletionSource.
• Det mest kraftfulla och avancerade verktyget i .NET för att hantera parallellism och asynkronitet är Task.
• C# async/await-operatörerna implementerar konceptet för icke-blockerande väntan.
• Distributionen av Tasks över trådar kan hanteras med hjälp av klasser som härstammar från TaskScheduler.
• Strukturen ValueTask kan vara användbar för att optimera hot-paths och minnesflöde.
• Fönstren Tasks och Threads i Visual Studio ger mycket användbar information för att felsöka tråd- eller asynkron kod.
• PLinq är ett fantastiskt verktyg, men det kan sakna tillräcklig information om din datakälla; detta kan dock åtgärdas med hjälp av partitionering.
• Fortsättning följer…

Källa: habr.com