.NET: Tööriistad mitme tahkete ja asünkroonsete protsesside jaoks. Osa 1

Avaldan artikli originaali Habris, mille tõlge on ettevõtte blogis.

Vajadus teha midagi asünkroonselt, mitte ootama tulemusi kohe ja praegu, või jagada suurt tööd mitme teostava üksuse vahel, oli olemas juba enne arvutite tulekut. Nende ilmumisega muutus see vajadus väga tuntavaks. Nüüd, 2019. aastal, kui ma seda artiklit kirjutades kasutan 8-ydre Intel Core protsessoriga sülearvutit, töötab paralleelselt mitte üks, vaid terve sadu protsesse, ja veel rohkem kulusid. Kõrval on mul veidi kulunud, paar aastat tagasi ostetud telefon, millel on 8-ydre protsessor. Teemakohastes allikates on palju artikleid ja videoid, kus nende autorid imetlevad selle aasta lipulaevade nutitelefone, kuhu paigutatakse 16-ydre protsessorid. MS Azure pakub vähem kui 20 $/tunnis virtuaalmasinat, millel on 128-ydre protsessor ja 2 TB RAM. Kahjuks on võimatu maksimaalselt ära kasutada ja valitseda seda jõudu, kui ei osata juhtida voogude vahelist suhtlemist.

Terminoloogia

Protsess (Process) — OS objekt, isoleeritud aadressiruumi, sisaldab vooge.
Voog (Thread) — OS objekt, väikseim täitmise ühik, protsessi osa, vood jagavad mälu ja muid ressursse omavahel protsessi piires.
Üheaegsus — OS omadus, võimalus täita samaaegselt mitu protsessi
Mitme tuuma kasutamine — protsessori omadus, võimalus kasutada andmete töötlemiseks mitut tuuma
Mitme protsessori kasutamine — arvuti omadus, võimalus töötada samaaegselt mitme füüsilise protsessoriga
Mitmekeelsus — protsessi omadus, võimalus jaotada andmete töötlemine mitme voolu vahel.
Paralleelsus — mitme tegevuse füüsiline samaaegne teostamine ühes ajas
Asünkroonsus — operatsiooni teostamine ilma selle töötlemise lõpetamise ootamata, tulemuse töötlemine võib toimuda hiljem.

Metafoor

Kõik määratlused ei ole head ja mõned vajavad täiendavat selgitust, seetõttu lisan formaalselt antud terminoloogiale hommikusöögi valmistamise metafoori. Hommikusöögi valmistamine selles metafooris on protsess.

Hommikusööki valmistades (CPU) tulen kööki (Arvuti). Mul on 2 kätt (Cores). Köögis on mitmeid seadmeid (IO): ahi, veekeetja, röster, külmkapp. Lülitan sisse gaasi, panen sellele panni ja valan sinna õli, ootamata, kuni see kuumeneb (asünkroonne, Non-Blocking-IO-Wait), võtan külmkapist munad ja löön need kaussi, seejärel vahustan ühes käes (Thread#1), samal ajal kui teise (Thread#2) hoian kaussi (Jagatud Ressurss). Praegu võiks ka veekeetjat sisse lülitada, aga käsi ei jätku (Thread Starvation) Selle aja jooksul kuumeneb pann (Tulemuste töötlemine), kuhu valan vahustatud segu. Ulatan veekeetjani ja lülitan selle sisse ja lihtsalt vaatan, kuidas vesi keema läheb (Blocking-IO-Wait), kuigi võiksin antud ajal nõud pesta, kus ma omletti vahustasin.

Valmistasin omleti kasutades vaid 2 kätt, rohkem mul ei ole, kuid samas omleti vahustamise ajal toimus korraga 3 tegevust: omleti vahustamine, kausi hoidmine, pann kuumutamine. CPU on arvuti kõige kiiremat osa, IO on see, mis tõrkeb sagedamini, seega on sageli efektiivne lahendus tegeleda millegagi CPU-ga, samal ajal kui andmeid saadakse IO-lt.

Jätkates metafoori:

• Kui omleti valmistamise ajal prooviksin ka riideid vahetada, oleks see mitmekesiste ülesannete täitmise näide. Oluline nüanss: arvutites on selle osas palju parem kui inimestel.
• Köök mitmete kokkadega, näiteks restoranis — mitme tuumaline arvuti.
• Palju restorane toidukohtades kaubanduskeskuses — andmekeskus

Tööriistad .NET

.NET on multitegumtöötluse puhul ja paljus muus head. Iga uue versiooniga tutvustatakse aina rohkem uusi tööriistu nendega töötamiseks, uusi abstraktsiooni kihte operatsioonisüsteemi (OS) voogude kohal. Abstraktsioonide loomisel kasutavad raamistikud lähtekohti, mis jätavad võimaluse kõrgetasemelise abstraktsiooni kasutamise ajal langetada madalamale tasemele või madalamatele tasanditele. Enamasti ei ole see vajalik, tõeliselt see avab võimaluse ennast juhuslikult vigastada, kuid mõnikord, harvadel juhtudel, võib see osutuda ainus viis probleemi lahendamiseks, mis ei lahene praegusel abstraktsioonitasemel.

Tööriistade all mõtlen ma nii tarkvaraliideseid (API) raamistikult ja kolmandatelt osapooltelt kui ka terviklikke tarkvaralahendusi, mis lihtsustavad mitme lõimekoodiga seotud probleemide leidmist.

Töö käivitamine

Thread klass, kõige põhilisem .NET-is lõimede töötlemiseks. Konstruktor võtab vastu ühe kahest delegaadist:

• ThreadStart — Ilma parameetriteta
• ParametrizedThreadStart — ühe object tüüpi parameetriga.

Delegaati täidetakse uues loodud lähtepunktis pärast Start meetodi kutsumist; kui konstruktorisse on edastatud ParametrizedThreadStart tüüpi delegaat, tuleb Start meetodile edastada objekt. See mehhanism on vajalik kohaliku info edastamiseks lõime. Tuleb märkida, et lõime loomine on kulukas operatsioon ning lõim on raske objekt, kuna vähemalt 1MB mälu eraldamine toimub virna jaoks ning see nõuab operatsioonisüsteemi API-ga suhtlemist.

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

ThreadPool klass esindab kontseptsiooni, mis on seotud puu kasutamisega. .NETis on lõimede puu inseneri kunst ja Microsofti arendajad on teinud palju pingutusi selle tagamiseks, et see töötaks optimaalselt erinevates stsenaariumides.

Üldine kontseptsioon:

Alates rakenduse käivitamisest loob ta taustal mitmeid reservlõime ja võimaldab kasutada neid. Kui lõime kasutatakse sageli ja suurtes kogustes, siis puu laieneb, et rahuldada kutsuva koodi vajadusi. Kui puus ei ole vaba lõime, ootab see kas mõne tagasi tuleku või loob uue. Seetõttu sobib lõimede puu suurepäraselt lühiajaliste toimingute jaoks, kuid ei sobi teenusteks, mis töötavad kogu rakenduse aja.

Lõime kasutamiseks puust on olemas meetod QueueUserWorkItem, mis võtab vastu WaitCallback tüüpi delegaat, mis on sama signatuuriga kui ParametrizedThreadStart, ja edastatud parameter täidab sama funktsiooni.

ThreadPool.QueueUserWorkItem(...);

Vähem tuntud meetod lõimede puus RegisterWaitForSingleObject teenib eesmärki korraldada mitteblokeerivaid IO-operatsioone. Delegaati, mis on edastatud sellele meetodile, kutsutakse üles siis, kui metoodile antud WaitHandle "vabastatakse" (Released).

ThreadPool.RegisterWaitForSingleObject(...)

.NET-is on lõime taimer, mis erineb WinFormsi/WPF taimeritest selle poolest, et selle handlerit kutsutakse välja puust võetud lõimes.

System.Threading.Timer

Samuti on olemas üsna eksootiline viis saata delegaat täitmiseks puust lõime — meetod BeginInvoke.

DelegateInstance.BeginInvoke

Soovin veel hetkeks peatuda funktsioonil, mille kutsumine on paljude eespool nimetatud meetodite keskmes — CreateThread Kernel32.dll Win32 API-s. On olemas viis, kuidas extern-mehhanismi abil seda funktsiooni kutsuda. Olen sellist kutsumist näinud vaid korra hirmuäratavas legacy koode näites, ning autori motivatsioon, miks ta just niimoodi tegutses, jääb mulle endiselt arusaamatuks.

Kernel32.dll CreateThread

Otsing ja silumistööd voogude üle

Teie isiklikult loodud vooge ning kõiki kolmanda osapoole komponente ja .NETi basseini vooge saab vaadata Visual Studio Threadsi aknas. See aken kuvab voogude teavet vaid siis, kui rakendus on silumises ja peatumise režiimis (Break mode). Siin on mugav vaadata igasuguste voogude steke, nimesid ja prioriteete ning suunata silumist konkreetsele voogule. Threadi klassi Priority omaduse abil saab määrata voolu prioriteedi, mida OC ja CLR tõlgendavad soovitusena voogude vahel protsessoriaega jagades.

Task Parallel Library

Task Parallel Library (TPL) ilmus .NET 4.0. See on nüüd standard ja peamine tööriist asünkroonsuse haldamiseks. Iga kood, mis kasutab vanemaid lähenemisviise, loetakse legacy-ks. TPL peamine osa on klass Task nimelaos System.Threading.Tasks. Task on abstraktsioon voost. Uue C# keele versiooniga saime elegantse viisi töötamiseks Task-idega — async/await operaatorid. Need kontseptsioonid võimaldasid kirjutada asünkroonset koodi justkui oleks see lihtne ja sünkrone, võimaldades isegi inimestele, kes ei mõista voogude sisemist toimimist, kirjutada rakendusi, mis ei seisku pikaajaliste tegevuste käigus. Async/awaiti kasutamine on teema ühe või isegi mitme artikli jaoks, kuid püüan lühidalt kokku võtta selle sisu:

• async on meetodi modifikaator, mis tagastab Taski või void'i.
• await on mitte-blokeeriv Task'i ootamise operaator.

Veel kordi: await operaator vabastab praegu toimiva syntaksile vastava sätte, ja kui Task lõpetab oma täitmise, jätkub meetodi täitmine, kui konteksti töötlus on lõpetatud. .NET-is on see mehhanism teostatud samamoodi nagu yield return, kui kirjutatud meetod muutub terveks klassiks, mis on oleku masin ja mida saab täita erinevate tükkide kaupa sõltuvalt nendest olekute olukordadest. Huvitav on kirjutada mõni lihtne kood asynс/await kasutades, kompileerida ja vaadata koostist JetBrains dotPeek abil, kus on lubatud Compiler Generated Code.

Vaadakem üle Taski käivitamise ja kasutamise võimalused. Allpool toodud koodi näitel loome uue ülesande, mis ei tee midagi kasulikku (Thread.Sleep(10000)), kuid tegelikus elus peaks see olema mingi keeruline CPU-d kasutav töö.

using TCO = System.Threading.Tasks.TaskCreationOptions;

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

    await Task.Factory.StartNew(
        // Tegevuskood täidetakse teises kontekstis
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    // Kood pärast await-i täidetakse salvestatud kontekstis
}

Task luuakse mitmete valikute abil:

• LongRunning — vihje, et ülesanne ei toimu kiiresti, seega on mõttekas mõelda sellele, et mitte võtta nišit teiselt registrilt, vaid luua selle ülesande jaoks eraldi.
• AttachedToParent — Task-id võivad paigutuda hierarhiatesse. Kui seda valikut on kasutatud, võib Task olla seisundis, kus see on ise lõpetatud ja ootab alampunktide täitmist.
• PreferFairness — tähendab, et oleks hea täita varem edastatud Task-e enne hiljem edastatud. Kuid see on vaid soovitus ja tulemus ei ole garanteeritud.

Teise parameetrina edastatakse meetodisse CancellationToken. Et õigesti käsitleda operatsiooni tühistamist pärast selle käivitamist, peaks täidetav kood olema täidetud CancellationToken tõendite staatuste kontrollidega. Kui kontrollid puuduvad, siis tühistamise meetod, mis kutsutakse esile objekti CancellationTokenSource pealt, suudab Task'i täitmise peatada ainult enne selle käivitamist.

Viimase parameetrina edastatakse objekti scheduler tüüp TaskScheduler. See klass ja selle alamlassi on mõeldud Task'ide jaotamisstrateegiate haldamiseks, vaikimisi täidetakse Task juhuslikul niidil basseinist.

Loodud Task'ile on rakendatud ooteoperaator await, see tähendab, et kood, mis on kirjutatud selle järel, kui see on, täidetakse samas kontekstis (tihti see tähendab, et samal niidil), mis on koodis enne await.

Meetod on märgitud async void, see tähendab, et selles on lubatud ooteoperaatori await kasutamine, kuid kutsuv kood ei saa ootama jääda selle täitmist. Kui see võimalus on vajalik, peab meetod tagastama Task. Async void märgitud meetodeid esineb üsna sageli: reeglina on need sündmuste käsitlejad või muud meetodid, mis töötavad põhimõttel teha ja unustada (fire and forget). Kui on vajalik mitte ainult võimaldada oodata täitmise lõppu, vaid ka tagastada tulemus, tuleb kasutada Task.

Task'il, mille meetod StartNew tagastas, saab aga nagu igal teiselgi, kutsuda meetodi ConfigureAwait parameetriga false, siis jätkub täitmine pärast await mitte püüdnud konteksti, vaid suvaliseks. Seda tuleb alati teha, kui koodi pärast await'i täitmise kontekst ei ole oluline. Samuti on see MS-i soovitus koodi kirjutamiseks, mis tarnitakse pakitud raamatukoguna.

Võtame veel hetkeks aega, et peatuda sellel, kuidas oodata Task'i täitmise lõppu. Allpool on koodinäide koos kommentaaridega, millal ootus on tehtud tinglikult hästi ja millal tinglikult halvasti.

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // hea

    result = AsyncMethod().Result; // halb

    AsyncMethod().Wait(); // halb

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

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

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

Esimeses näites ootame Task'i täitmise lõpuni, blokeerimata kutsuvat niiti, tulemuse töötlemisse naaseme vaid siis, kui see on juba olemas, kuni siis on kutsuv niit iseendale usaldatud.

Teises variandis blokeerime kutsevoo, kuni meetodi tulemus on arvutatud. See on halb mitte ainult seetõttu, et oleme kasutanud voogu, mis on programmi väärtuslik ressurss, lihtsalt passiivselt, vaid ka seetõttu, et kui kutsemeetodis, mida kutsume, on await, ja sünkroniseerimise kontekst eeldab tagasi tagasiviimist kutsevoogu pärast await'i, saame deadlock'i: kutsevoog ootab, kuni asünkroonne meetod on tulemuse arvutanud, samas kui asünkroonne meetod püüab asjatult jätkata oma täitmist kutsevoos.

Veel üheks selle lähenemise puuduseks on keerulisem veahaldus. Asi on selles, et asünkroonse koodi vigade käsitlemine async/await abil on väga lihtne — need käituvad nagu oleks kood sünkroonne. Samas, kui kasutame sünkroonset ootamist Task'i puhul, originaalväljavõte pakitakse AggregateException'i, mistõttu tuleb erandi käsitlemiseks uurida InnerException'i tüüpi ja kirjutada ise if-ahel ühe catch-bloki sees või kasutada catch when konstruktsiooni, selle asemel, et kasutada C# maailmas harjumuslikku catch-blokkide ahelat.

Kolmas ja viimane näide on samuti halb sama põhjuse tõttu ja sisaldab kõiki neid samu probleeme.

Meetodid WhenAny ja WhenAll on äärmiselt mugavad grupi Task'ide ootamiseks, need pakivad grupi Task'e ühte, mis aktiveerub kas esimesena toimiva Task'i või siis kui kõik on lõpetanud oma täitmise.

Voogude peatamine

Erinevatel põhjustel võib tekkida vajadus peatada voog pärast selle käivitamist. Selleks on olemas mitmeid viise. Thread'i klassil on kaks meetodit sobivate nimede järgi — see on Abort ja Interrupt. Esimene ei ole rangelt soovitatav kasutada, kuna pärast selle kutsumist visatakse juhuslikul hetkel, igasuguses käskluste töötlemises, erand ThreadAbortedException. Te ei oota, et selline erand ilmuks, kui inkrementeerite mõnda täisarvu muutujaid, eks? Aga selle meetodi kasutamisel on see täiesti reaalne olukord. Kui on vajalik keelata CLR-i genereerimine selliste erandite jaoks teatud koodilõigus, saab selle pakkida Thread.BeginCriticalRegion, Thread.EndCriticalRegion. Iga kood, mis on kirjutatud finally plokki, käitub selliste väljakutsete tõttu. Sellepärast võib raamistikust leida plokke, kus try on tühi, aga finally mitte. Microsoft ei soovita seda meetodit kasutada nii palju, et nad ei lisanud seda .net core'i.

Meetod Interrupt töötab ennustatavamalt. See võib katkestada lõime erandiga. ThreadInterruptedException ainult siis, kui lõim on ooterežiimis. Sellisesse olekusse ta läheb, kui ootab WaitHandle'i, lock'i või pärast Thread.Sleep'i kutsumist.

Mõlemad ülaltoodud variandid on ebamugavad oma ettearvamatuse tõttu. Lahenduseks on kasutada struktuuri CancellationToken ja klassi CancellationTokenSource. Idee on järgmine: luuakse CancellationTokenSource klassi eksemplar ja ainult selle omanik võib peatada operatsiooni, kutsudes välja meetodi Cancel. Samas operatsioonis edastatakse ainult CancellationToken. CancellationToken'i omanikud ei saa ise operatsiooni tühistada, vaid saavad ainult kontrollida, kas operatsioon on tühistatud. Selleks on olemas boolean omadus IsCancellationRequested ja meetod ThrowIfCancelRequested. Viimane genereerib erandi TaskCancelledException kui CancellationTokenSource'i eksemplaris, mis oli seotud CancellationToken'iga, kutsuti välja meetod Cancel. Just seda meetodit soovitan kasutada. See on parem kui eelnevad variandid, pakkudes täielikku kontrolli selle üle, millal võib operatsioonis esinev erand olla katkestatud.

Kõige drastilisem variant lõime peatamiseks on Win32 API funktsiooni TerminateThread kutsumine. CLR-i käitumine pärast selle funktsiooni kutsumist võib olla ettearvamatu. MSDN-is kirjutatakse selle funktsiooni kohta järgmist: “TerminateThread is a dangerous function that should only be used in the most extreme cases. “

Legacy-API muutmine ülesande põhistel meetoditel kasutades FromAsync meetodit.

Kui teil on vedanud töötada projektis, mis alustati pärast seda, kui ülesanded olid sisse viidud ja enam ei põhjustanud enamiku arendajate vaikset hirmu, siis ei pea te tegelema suure hulga vanade API-dega, olgu need siis kolmandate osapoolte või teie meeskonna minevikus välja mõeldud. Õnneks on .NET Frameworki arendustiim meie eest hoolt kandnud, ehkki võib-olla oli eesmärk hoolitseda enda eest. Igal juhul on .NET-is mitmeid tööriistu, mis võimaldavad valutult muuta vana asünkroonse programmeerimise lähenemisviisi uuteks. Üks neist on Meetod FromAsync klassis TaskFactory. Alloleva näite puhul pakendan vanad asünkroonsed meetodid klassis WebRequest Task’i, kasutades seda meetodit.

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

See on vaid näide ja sellist asja ei ole teil tõenäoliselt vaja teha sisseehitatud tüüpidega, kuid iga vana projekt on täis meetodeid BeginDoSomething, mis tagastavad IAsyncResult ning meetodeid EndDoSomething, mis neid vastu võtavad.

Legacy-API muutmine ülesande põhisteks klassi TaskCompletionSource abil

Veel üks oluline tööriist, mida arvestada, on klass TaskCompletionSource. Funktsioonide, eesmärgi ja tööpõhimõtte poolest võib see meenutada klassi ThreadPool meetodit RegisterWaitForSingleObject, millest ma varem rääkisin. Selle klassi abil on lihtne ja mugav vanu asünkroonseid API-sid Task'idesse pakendada.

Te ütlete, et ma olen juba rääkinud klassi TaskFactory meetodist FromAsync, mis on selleks otstarbeks mõeldud. Siin tuleb meelde tuletada kõiki .NET asünkroonsete mudelite arengulugusid, mida Microsoft on pakunud viimase 15 aasta jooksul: enne Task-Based Asynchronous Pattern (TAP) oli olemas Asynchronous Programming Pattern (APP), mis põhines meetoditel BeginDoSomething, mis tagastavad IAsyncResult ja meetoditel EndDoSomething, mis neid vastu võtavad ning vanadele aastatele sobib suurepäraselt meetod FromAsync, kuid aja jooksul asendas selle Event Based Asynchronous Pattern (EAP), mis nägi ette, et asünkroonse toimingu lõpetamisel kutsub esile sündmuse.

TaskCompletionSource on ideaalne lahendus legacy-API-de mähkimiseks, millel on ürituste mudel. Selle töö põhiolemus seisneb selles, et selle klassi objektil on avalik omadus tüübiga Task, mille olekut saab hallata meetodite SetResult, SetException jne. kaudu. TaskCompletionSource klassi kohta. Seal, kus on kasutatud ooteoperatsiooni await selle Task’i puhul, täidetakse see või visatakse välja erind, sõltuvalt sellest, millist meetodit rakendati TaskCompletionSource'ile. Kui see ei ole endiselt selge, siis vaatame seda näidet koodist, kus mõni vana API EAP ajast mähitakse Task'i abil TaskCompletionSource'iga: kui sündmus aktiveerub, muudetakse Task seisundiks Completed ja meetod, mis rakendas sellele Task’ile ooteoperatsiooni await, jätkab täitmist, saades objekti. result.

public static Task DoAsync(this SomeApiInstance someApiObj) {

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

    return completionSource.Task;
}

TaskCompletionSource Näpunäited ja Trikid

Vana API mähkimine ei ole ainus asi, mida TaskCompletionSource abil teha saab. Selle klassi kasutamine avab huvitavaid võimalusi erinevate API-de projekteerimiseks, mis põhinevad Task'idel, mis ei hõivata teemasid. Ja teema, nagu me teame, on kallis ressurss ning nende arv on piiratud (peamiselt RAMi mahuga). Seda piirangut on lihtne saavutada, arendades näiteks koormatud veebirakendust keerulise äriloogikaga. Uurime neid võimalusi, millest ma räägin, rakendades sellist trikki nagu Long-Polling.

Lühidalt, triki sisu on järgmine: peate saama API-lt teavet mõnedest sündmustest, mis toimuvad sellel poolel, kuid mingil põhjusel ei saa API sündmust teatada, vaid saab ainult tagastada oleku. Sellisteks näideteks on kõik API-d, mis on loodud HTTP peal enne WebSocketi aega või kui mingil põhjusel ei saa seda tehnoloogiat kasutada. Klient võib HTTP serverilt küsida. HTTP server ei saa ise klientidega suhelda. Lihtne lahendus on serveri küsitlemine ajastuse kaudu, kuid see koormab serverit ning tekitab keskmise viivituse TimerInterval / 2. Selle mööda minemiseks leiutati trikk nimega Long Polling, mis eeldab serverilt vastuse viivitamist seni, kuni aegumise ajalimiit lõppeb või sündmus toimub. Kui sündmus toimub, siis see töödeldakse; kui ei, siis saadetakse päring uuesti.

while(!eventOccures && !timeoutExceeded)  {

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

Kuid selline lahendus näitab end kohutavalt, kui ootavate klientide arv kasvab, kuna iga selline klient, kes ootab sündmust, kasutab üht eraldi lõime. Samuti saame lisaviivituse 1 ms sündmuse toimumisel, mis enamasti ei ole oluline, kuid miks teha tarkvara halvemaks, kui see võiks olla? Kui eemaldada Thread.Sleep(1), koormame ühte CPU tuuma 100% ulatuses, pöörledes kasutu tsükli sees. TaskCompletionSource abil saab seda koodi lihtsasti ümber kujundada ja lahendada kõik varem mainitud probleemid:

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);
    }
}

See kood ei ole production-ready, vaid ainult näidis. Reaalsetes olukordades tuleb veel vähemalt hallata olukord, kus sõnum saabus hetkel, kui keegi seda ei oota: sellisel juhul peaks meetod AcceptMessageAsync tagastama juba lõpetatud Task'i. Kui see juhtum on kõige sagedasem, siis võib mõelda ka ValueTask'i kasutusele.

Küsimuse saamisel loome ja paneme sõnastikku TaskCompletionSource, ning ootame, mis juhtub esimesena: kas aeg on möödas või saadakse sõnum.

ValueTask: miks ja kuidas

Async/await operaatorid, nagu ka yield return operaator, genereerivad meetodist olekute masina, mis tähendab, et luuakse uus objekt. See on enamasti ebaoluline, kuid harvadel juhtudel võib see tekitada probleeme. Selliseks juhtumiks võib olla meetod, mida kutsutakse tõeliselt sageli, kümneid ja sadu tuhandeid kordi sekundis. Kui selline meetod on kirjutatud nii, et enamikul juhtudel tagastab ta tulemuse, möödudes kõigist await meetoditest, siis .NET pakub tööriista selle optimeerimiseks — ValueTask struktuur. Et seda paremini mõista, vaatame selle kasutamise näidet: meil on vahemälu, kuhu me käime väga sageli. Mõned väärtused on seal ja siis me tagastame need otse, kui neid pole, siis läheneme mõnele aeglasele IO-le nende saamiseks. Viimast soovime teha asünkroonselt, mistõttu kogu meetod osutub asünkroonseks. Seega ilmselge variant meetodi kirjutamiseks on järgmine:

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

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

Soovi korral natuke optimeerida ja väikese kartuse tõttu, mida Roslyn sellega genereerib, saame seda näidet kirjutada järgmiselt:

public Task<string> GetById(int id) {

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

Optimaalse lahendusena oleks sel juhul optimeerida kuuma tee, nimelt, saada väärtust sõnastikust ilma liigsete allokatsioonide ja GC koormuseta, samas kui harvadel juhtudel, kui me peame minema IO-sse andmete saamiseks, jääb kõik enam-vähem samaks:

public ValueTask<string> GetById(int id) {

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

Vaatame seda koodifragmendi lähemalt: kui vahemälus on väärtus, loome struktuuri, vastasel juhul on tegelik ülesanne pakitud väärtuslikku. Kutsuv kood ei hooli, millisest teest see kood käidi: ValueTask käitub C# süntaksist vaadatuna samamoodi nagu tavaline Task.

TaskScheduler’id: Task’ide käivitamise strateegiate haldamine

järgmine API, mida sooviksime vaadata, on klass TaskScheduler ja selle tuletised. Olen juba eespool maininud, et TPL-is on võimalik hallata ülesannete jaotamise strateegiaid lõimede vahel. Sellised strateegiad määratakse ülesande ajakava klassi pärijates. Peaaegu iga strateegia, mida võib vaja minna, leiab raamatukogust. ParallelExtensionsExtras, mille on välja töötanud Microsoft, kuid mis ei ole osa .NET-ist ja tarnitakse Nuget paketi vormis. Vaadakem lühidalt mõningaid neist:

• CurrentThreadTaskScheduler — täidab ülesandeid praegusel lõimel.
• LimitedConcurrencyLevelTaskScheduler — piirab samaaegselt täidetavate ülesannete arvu parameetriga N, mille ta võtab konstruktoris.
• OrderedTaskScheduler — määratletakse kui LimitedConcurrencyLevelTaskScheduler(1), seega täidetakse ülesanded järjestikku.
• WorkStealingTaskScheduler — rakendab töövarastamise lähenemist ülesannete jaotamisele. Tegelikult on see eraldi lõimede bassein. See lahendab probleemi, et .NET-i lõimede bassein on staatiline klass, üks kõikide rakenduste jaoks, mistõttu võivad selle ülekoormus või vale kasutamine ühes rakenduse osas põhjustada kõrvalmõjusid teises. Veelgi enam, selliste defektide põhjuse mõistmine on äärmiselt keeruline. Seega võib olla vajalik kasutada eraldi WorkStealingTaskScheduler-e rakenduse osades, kus lõimede basseini kasutamine võib olla agressiivne ja ettearvamatu.
• QueuedTaskScheduler — võimaldab täita ülesandeid prioriteediga järjekorra reeglite järgi.
• ThreadPerTaskScheduler — loob iga ülesande täitmiseks eraldi lõime. See võib olla kasulik ettearvamatult pikka aega täidetavate ülesannete jaoks.

Microsofti blogis on hea ja põhjalik artikkel teave ülesande ajakava kohta.

Kogu ülesannetega seotud võimaluste lihtsaks tõrkeotsimiseks Visual Studios on olemas ülesannete aken. Selles aknas saab näha ülesande praegust seisu ja liikuda hetkel täidetava koodi ritta.

PLinq ja klass Parallel

Lisaks Task'idele ja kõigile, mis nendega seondub .NET-s, on veel kaks huvitavat tööriista, nimelt PLinq (Linq2Parallel) ja klass Parallel. Esimene lubab paralleelset täitmist kõigist Linq operatsioonidest mitmel lõngal. Lõngade arvu saab konfigureerida laienduse Meetodiga WithDegreeOfParallelism. Kahjuks ei piisa PLinq-lt vaikerežiimis sageli teabest teie andmeallika sisust, et saavutada märkimisväärne kiirusvõit, kuid katse tegemise hind on väga madal: peate lihtsalt enne Linq meetodite ahelat kutsuma AsParallel meetodi ja teostama jõudlusteste. Veelgi enam, PLinq-le on võimalik edastada täiendavat teavet andmeallika iseloomu kohta Partitions mehhanismi abil. Täiendavalt on võimalik lugeda siin ja siin.

Statiline klass Parallel pakub meetodeid kollektsiooni paralleelseks läbimiseks Foreach, For tsükli täitmiseks ja mitme delegaadi paralleelseks käivitamiseks Invoke. Praeguse lõnga täitmine peatub, kuni arvutuste lõpetamiseni. Lõngade arvu saab konfigureerida, edastades ParallelOptions viimase argumendina. Valikute abil on samuti võimalik määrata TaskScheduler ja CancellationToken.

Järeldused

Kui ma hakkasin kirjutama seda artiklit oma ettekande ja selle ajal kokku kogutud teabe põhjal, ei oodanud ma, et sellest tuleb nii palju. Praegu, kui tekstiredaktor, kus ma seda artiklit tippin, piidleb mulle näidates, et leht on juba 15. kohal, teen vahekokkuvõtte. Teised trikid, API-d, visuaalsed tööriistad ja alajaotused käsitletakse järgmises artiklis.

Kokkuvõtted:

• On oluline tunda tööriistu lõngade, asünkroonsuse ja paralleelsuse käsitlemiseks, et kasutada tänapäevaste arvutite resursse.
• .NET-is on nende eesmärkide saavutamiseks palju erinevaid tööriistu
• Need ei ilmunud kõik kohe, seetõttu võib sageli kohata legacy lahendusi, kuid vana API-d on võimalik konverteerida ilma suuremate jõupingutusteta.
• .NET-is käsitletakse lõngadega töötamist klasside Thread ja ThreadPool kaudu
• Meetodid Thread.Abort, Thread.Interrupt ja Win32 API funktsioon TerminateThread on ohtlikud ja nende kasutamist ei soovitata. Selle asemel on parem kasutada CancellationToken mehhanismi.
• Voog on väärtuslik ressurss, mille kogus on piiratud. Tuleb vältida olukordi, kus vood ootavad sündmusi. Selleks on mugav kasutada klassi TaskCompletionSource
• Kõige võimsamad ja arenenumad .NET tööriistad paralleelsuse ja asünkroonsuse jaoks on Task'id.
• C# async/await operaatorid realiseerivad mitteblokeeriva oote kontseptsiooni
• Task'ide jaotamist voogude vahel saab hallata tuletatud TaskScheduler'i klasside abil
• ValueTask struktuur võib olla kasulik hot-pathide ja mälu liikluse optimeerimisel
• Visual Studio Tasks ja Threads aknad pakuvad palju kasulikku teavet mitme töötluse või asünkroonse koodi tõrkeotsingu jaoks
• PLinq on äge tööriist, kuid see ei pruugi teie andmeallika kohta piisavalt teavet omada, kuid seda saab parandada jagamise mehhanismi abil
• Jätkub…

Allikas: habr.com