.NET: Tööriistad üheaegsuse ja asünkroonsuse jaoks. Osa 1

Avaldan Habr'is artikli originaali, mille tõlge on ettevõtte blogis.

Vajadus teha midagi asünkroonselt, oodates tulemusi siin ja praegu, või jagada suurt tööd mitme täitmise üksuse vahel, eksisteeris juba enne arvutite teket. Arvutite tulekuga muutus see vajadus väga tuntavaks. Praegu, 2019. aastal, kirjutades seda artiklit Intel Core'i 8 tuumaga sülearvutis, mis samal ajal käitab mitte ühte sada protsessi, vaid veelgi rohkem niite. Kõrval lebab veidi kulunud telefon, mis osteti paar aastat tagasi ja millel on 8 tuumaga protsessor. Teemakohastes ressurssides on hulk artikleid ja videoid, kus nende autorid imetlevad tänavuste lipulaevade nutitelefone, kuhu on paigaldatud 16 tuumaga protsessorid. MS Azure pakub vähem kui 20 $ / tunni eest virtuaalmasinat, millel on 128 tuumaga protsessor ja 2 TB RAM. Kahjuks on võimatu saavutada maksimaalset kasu ja taltsutada seda jõudu, kui ei osata hallata niitide koostööd.

Terminoloogia

Protsess (Process) — OS objekt, isoleeritud aadressiruum, sisaldab niite.
Niit (Thread) — operatsioonisüsteemi objekt, väikseim täitmise kogus, protsessi osa, mille jooksul niidid jagavad mälu ja muid ressursse üksteisega protsessi raames.
Mitme ülesande täitmine — operatsioonisüsteemi omadus, mis võimaldab samaaegselt täita mitut protsessi
Mitme südamiku olemasolu — protsessori omadus, mis võimaldab kasutada mitut südamikku andmete töötlemiseks
Mitme protsessori olemasolu — arvuti omadus, mis võimaldab füüsiliselt samaaegselt töötada mitme protsessoriga
Mitme niidi olemasolu — protsessi omadus, mis võimaldab andmete töötlemist jagada mitme niidi vahel.
Paralleelsus — mitme tegevuse füüsiline samaaegne täitmine ajaühikus
Asünkroonsus — operatsiooni täitmine ilma ootamata selle töötlemise lõpuleviimist, tulemuse töötlemine võib toimuda hiljem.

Metafora

Kaugelki kõik määratlused ei ole head ja mõned vajavad täiendavat selgitust, seetõttu lisan formaalselt sisseviidud terminoloogiale hommikusöögi tegemise metafora. Hommikusöögi valmistamine selles metaforas on process.

Hommikust süüa valmistades (CPU) astun ma kööki (Arvuti). Mul on 2 kätt (Südamikud). Köögis on mitmeid seadmeid (IO): ahju, veekeetja, röster, külmik. Lülitan gaasi sisse, panen pannile ja valan sinna õli, ootamata, kuni see kuumeneb (asünkroonselt, Non-Blocking-IO-Wait), tõmban külmikust välja munad ja löön need kaussi, seejärel vahustan ühe käega (Thread#1), samas kui teisega (Thread#2) hoian kaussi (Shared Resource). Praegu võiks ka veekeetjat sisse lülitada, aga käsi pole piisavalt (Thread Starvation) Selle aja jooksul kuumeneb pann (Tulemuse töötlemine), kuhu valan vahustatud segu. Tõmban veekeetja ligi ja lülitan selle sisse ning vaatangi lihtsalt, kuidas vesi keeb (Blocking-IO-Wait), kuigi oleksin saanud selle aja jooksul nõusid pesta, kus vahustasin omletti.

Valmistasin omletti, kasutades ainult 2 kätt, rohkem mul pole, aga samas vahustamise hetkel toimusid korraga 3 operatsiooni: omleti vahustamine, kausi hoidmine, pannikuumuse tõstmine. CPU on arvuti kõige kiirem osa, IO on see, mis tihti mahutab, seega on sageli efektiivne lahendus hoida CPU tegevuses, samal ajal kui IO andmete hankimine toimub.

Jätkates metafoori:

• Kui mulle peaks omletti küpsetades samal ajal riideid vahetama, oleks see multitasking. Oluline nüanss: selles osas on arvutid palju paremad kui inimesed.
• Köök mitme kokaga, nagu restoranis — mitme tuumaga arvuti.
• Palju restorane toidukohtades kaubanduskeskuses — andmekeskus.

Tööriistad .NET.

.NET on voogude haldamisel samuti nagu paljus muus hea. Iga uue versiooniga tutvustatakse järjest rohkem uusi tööriistu nende haldamiseks ning uusi abstraheerimise kihte opsüsteemi voogude peale. Abstraheerimise ülesehitamisel kasutab raami arendaja lähenemist, mis võimaldab kõrgetasemelise abstraktsiooni kasutamisel laskuda ühe või mitme taseme võrra madalamale. Kõige sagedamini ei ole selles vajadust, isegi rohkem, see avab võimaluse endale kahuripauguga jalga tulistada, kuid mõnikord, harvadel juhtudel, võib see olla ainus viis probleemi lahendamiseks, mis ei lahene praegusel abstraktsioonitasemel.

Tööriistade all mõtlen ma nii tarkvaraliideseid (API), mida pakuvad raamistikud ja kolmandate osapoolte paketid, kui ka täielikke tarkvaralahendusi, mis lihtsustavad mitme lõime koodiga seotud probleemide leidmist.

Lõime käivitamine

Thread klass, kõige alus .NET'is lõime töötamiseks. Konstruktorisse võetakse üks kahest delegeeritust:

• ThreadStart — pole parameetreid
• ParametrizedThreadStart — ühe parameetriga tüübiga object.

Delegeeritud käivitatakse äsja loodud lõimes pärast Start meetodi kutsumist. Kui konstruktorisse on antud delegeeritud tüüp ParametrizedThreadStart, siis tuleb Start meetodile edastada objekt. See mehhanism on vajalik, et edastada igasugust kohalikku teavet lõime. Tuleb märkida, et lõime loomine on kulukas operatsioon ja lõim ise on keeruline objekt, kuna vähemalt 1 MB mälu eraldatakse virnale ning see nõuab suhtlemist operatsioonisüsteemi API-ga.

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

ThreadPool klass esindab puulide kontseptsiooni. .NET-is on lõimede bassein tehnilise meisterlikkuse teos ja Microsofti arendajad on teinud tohutult palju pingutusi, et see töötaks erinevates stsenaariumides optimaalselt.

Ühine kontseptsioon:

Alates rakenduse käivitamisest loob rakendus taustal mitu reservi lõime ja pakub neid kasutada. Kui lõime kasutatakse sageli ja suures koguses, siis laieneb reserv, et rahuldada kutse koodi vajadusi. Kui teatav hetk ei ole vabas reservis vabu lõime, ootab see kas ühe lõime tagasitulekut või loob uue. Seega sobib lõimede reserv suurepäraselt lühikesteks toiminguteks ja on halvem valik teenusteks, mis töötavad rakenduste kogu tööaja jooksul.

Reservist lõime kasutamiseks on olemas meetod QueueUserWorkItem, mis aktsepteerib WaitCallback tüüpi delegaat, mis vastab parametreeritud lõime algatamise signatuurile, ja sellele edasi antud parameeter täidab sama funktsiooni.

ThreadPool.QueueUserWorkItem(...);

Vähem tuntud meetod lõimede reservist RegisterWaitForSingleObject on mõeldud blokeerivate IO-opatsioonide korraldamiseks. See meetod kutsub esile delegaadi, kui selle meetodiga antud WaitHandle on „vabastatud“ (Released).

ThreadPool.RegisterWaitForSingleObject(...)

Kui .NET-is on voogude taimer, erineb see WinForms/WPF taimeritest sellega, et selle käsitleja kutsutakse välja basseinist võetud voos.

System.Threading.Timer

On ka üsna eksootiline viis edastada delegaat täitmiseks basseinist voosse — meetod BeginInvoke.

DelegateInstance.BeginInvoke

Soovin veel vaevu peatuda funktsioonil, millele paljuski viitavad eespool nimetatud meetodid — CreateThread Kernel32.dll Win32 API-s. On olemas võimalus, tänu extern meetodite mehhanismile, kutsuda seda funktsiooni. Olen näinud sellist kutsumist ainult kord hirmsas vanas koodinäites, ja autori motivatsioon, kes just nii tegutses, jääb mulle ikka veel mõistatuseks.

Kernel32.dll CreateThread

Voogude vaatamine ja tõrkeotsing

Teie loodud kõik kolmandate osapoolte komponentide ja .NET programmivekte võib Visual Studio Threadsi aknas vaadata. See aken kuvab teavet ainult siis, kui rakendus on silumisrežiimis ja katkestatud. Siin saab mugavalt vaadata iga tee steki nimesid ja prioriteete, samuti suunata silumist konkreetsele teele. Threadi klassi Priority omadus võimaldab määrata tee prioriteedi, mida OC ja CLR mõistavad soovitusena, kui jagatakse protsessoritööaega tee vahel.

Task Parallel Library

Task Parallel Library (TPL) ilmus välja .NET 4.0. Täna on see standardne ja peamine tööriist asünkroonsuse rakendamiseks. Iga kood, mis kasutab vanemaid lähenemisi, loetakse pärandiks. TPL põhiühik on Task klass, mis kuulub süsteemi System.Threading.Tasks. Task esindab abstraktsiooni lõngast. Uue C# versiooniga saime elegantse viisi Task`idega töötamiseks — async/await operaatorid. Need kontseptsioonid võimaldavad kirjutada asünkroonsed koodid justkui need oleksid lihtsad ja sünkroossed, andes võimaluse isegi neile, kes ei mõista sügavalt lõngade toimimist, luua rakendusi, mis ei jää kinni pikade operatsioonide täitmisel. Async/await kasutamine on teema, mis väärib vähemalt ühte, kui mitte rohkem artiklit, kuid ma üritan lühidalt kokku võtta selle sisemise tähenduse:

• async on meetodi modifikaator, mis tagastab Task või void
• ja await on Task`i mitteblokeeriv ootamise operaator.

Kordame: await operaator, üldiselt (on erandeid), laseb praegusel täitmisvoolul edasi minna, ja kui Task lõpetab oma täitmise, siis kui kontekst (tõeliselt on õigem öelda kontekst, aga sellest hiljem) on vaba, jätkab meetodi täitmisega edasi. .NET-is on see mehhanism rakendatud sarnaselt yield return'iga, kui kirjutatud meetod muudetakse tervikuks klassiks, mis on olekute masin ja saab täita eraldi osades, sõltuvalt nendest olekutest. Need, keda huvitab, võivad kirjutada mis tahes lihtsa koodi asynс/await kasutades, kompileerida selle ja vaadata kogumit JetBrains dotPeek'iga, aktiveeritud Compiler Generated Code'iga.

Vaatame Task'i käivitamise ja kasutamise võimalusi. Allolevas koodis loome uue task'i, mis ei tee midagi kasulikku (Thread.Sleep(10000)), kuid reaalses elus peaks see olema mingi keeruline protsessorit mõjutav töö.

kasutades TCO = System.Threading.Tasks.TaskCreationOptions;

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

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

    // Kood pärast awaiti täidetakse kinni haaratud kontekstis
}

Task luuakse rea valikutega:

• LongRunning — vihje, et ülesanne ei pruugi kiiresti täidetav olla, seega oleks mõistlik kaaluda, et mitte kasutada thread’it puul, vaid luua eraldi selle Task’i jaoks, et mitte kahjustada teisi.
• AttachedToParent — Task’id võivad moodustada hierarhia. Kui see valik on tehtud, võib Task olla seisundis, kus see on ise täidetud ja ootab alamülesannete täitmist.
• PreferFairness — tähendab, et oleks hea täita varem saadetud Task’id enne hiljem saadetud ülesandeid. Kuid see on vaid soovitus ja tulemuse tagamine ei ole garanteeritud.

Teiseks parameetriks, mis meetodile edastatakse, on CancellationToken. Et töötlus toimuks õigesti pärast tegevuse käivitamist, peab täidetav kood sisaldama CancellationTokeni oleku kontrollimise kontrolle. Kui kontrollimist pole, siis saab CancellationTokenSource'ilt kutsutud Cancel meetod peatada Task'i ainult enne selle käivitamist.

Viimaseks parameetriks on edastatud TaskScheduler tüüpi objekt scheduler. See klass ja selle alamklassid on mõeldud Task'ide jaotamisstrateegiate haldamiseks, vaikimisi täidetakse Task juhuslikul niidi jooksul pidevas niidi plokis.

Loodud Taskile on rakendatud await operaator, mis tähendab, et pärast seda kirjutatud kood, kui selline on, täidetakse samas kontekstis (tihti tähendab see, et samas niidis), nagu oli kood enne await'i.

Meetod on märgistatud kui async void, mis tähendab, et see lubab kasutada await operaatorit, kuid kutsuv kood ei saa oodata täitmist. Kui see on vajalik, peaks meetod tagastama Task’i. Async void meetodeid esineb üsna sageli: tavaliselt on need sündmuste töötlejate või teiste meetodite puhul, mis toimivad põhimõttel 'tee ja unusta' (fire and forget). Kui on vajalik võimalus oodata täitmise lõppu ja tagastada tulemus, tuleb kasutada Task’i.

Task’ilt, mille meetod StartNew tagastas, saab nagu igalt teiselt, kutsuda välja ConfigureAwait meetodi false parameetriga, sel juhul jätkub täitmine pärast await’i mitte haaratud kontekstis, vaid suvalises. Seda tuleb alati teha, kui await’i järgneva koodi täitmise kontekst ei ole oluline. See on ka MS-i soovitus koodi kirjutamisel, mis pakendatakse teegina.

Vaatame veel natuke, kuidas saab oodata Task’i täitmise lõppu. Allpool on koodinäide koos kommentaaridega, kus ootamine on tehtud tinglikult hästi ja kus 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, kuni ülesanne on lõpule viidud, ilma et peataksime kutsuva täitev, tulemuse töötlemisse naaseme alles siis, kui see on juba saadaval, kuni selle ajani kutsev täitev jääb endale.

Teises variandis peatame kutsuva täitevni, kuni meetodi tulemus on arvutatud. See on halb, mitte ainult seetõttu, et oleme kinni hoidnud niivõrd väärtuslikku ressursi, nagu täitev, vaid ka seetõttu, et kui meetodi taastumise koodis on await ja sünkroneerimise kontekst eeldab, et pärast await naaseme originaalsesse täituvasse, saame deadlock'i: kutsuv täitev ootab, kuni asünkroonne meetod on arvutatud, asünkroonne meetod üritab meeleheitlikult jätkata oma täitmist kutsuvas täites.

Üks sellise lähenemise puudusi on vea töötlemise keerukus. Asynchronous koodiga töötades on async/await vead väga lihtsalt töödeldavad — need käituvad nagu sünkroonne kood. Kui aga rakendame sünkroonset oote protsessi, siis originaalne erand mähitakse AggregateException'i, mistõttu selle töötlemiseks tuleb uurida InnerException tüüpi ja kirjutada omamoodi if-ahel ühe catch ploki sees või kasutada catch when konstruktsiooni, selle asemel et kasutada C# maailmas tuttavaid catch plokkide ahelat.

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

Meetodid WhenAny ja WhenAll on äärmiselt mugavad Task’ide grupi oote tegemiseks, nad mähivad Task’ide grupi ühte, mis aktiveerub kas esimesel Task’il rikke korral või siis, kui kõik on oma täitmise lõpetanud.

Protsesside peatamine

Erinevatel põhjustel võib tekkida vajadus peatada protsess pärast selle käivitamist. Selleks on olemas mitmeid meetodeid. Thread klassil on kaks meetodit sobivate nimedega — need on Abort ja Interrupt. Esimene on äärmiselt ebasoovitav, kuna selle kutsumise tõttu viskatakse erand juhuslikul hetkel, olenemata millise käsu töötlemisest. ThreadAbortedException. Te siiski ei oota, et selline erand tekib mingi täisarvu muutuja suurendamise ajal, eks? Kuid selle meetodi kasutamisel on see täiesti reaalne olukord. Kui on vajadus keelata CLR-i genereerida selline erand teatud koodilõigus, saab seda ümbritseda kutsetega. Thread.BeginCriticalRegion, Thread.EndCriticalRegion. Need kutsed ümbritsevad kogu koodi, mis on kirjutatud finally plokki. Sellepärast võib raamistiku koodist leida tühjad try plokid, kuid mitte tühjad finally plokid. Microsoft ei soovita seda meetodit kasutada nii väga, et nad ei ole seda sisse lükanud .net core'i.

Meetod Interrupt töötab ennustatavamalt. See võib katkestada niidi erandi ThreadInterruptedException ainult siis, kui niit on ooteseisundis. Sellesse olekusse siseneb see, kui see jääb ootele WaitHandle'i, lukustuse (lock) või pärast Thread.Sleep'i kutset.

Mõlemad ülaltoodud variandid on halvad oma ennustamatuse tõttu. Lahenduseks on struktuuri kasutamine. CancellationToken ja klassi CancellationTokenSource. Käibekäik on järgmine: luuakse CancellationTokenSource klassi eksemplar, ja ainult selle omanik saab lõpetada operatsiooni, kutsudes välja meetodi Cancel. Operatsiooni edastatakse ainult CancellationToken. CancellationToken'i omanikud ei saa operatsiooni ise lõpetada, kuid nad saavad kontrollida, kas operatsioon on lõpetatud. Selle jaoks on boolean omadus IsCancellationRequested ja meetod ThrowIfCancelRequested. Viimane genereerib erandi TaskCancelledException kui kutsutakse välja Cancel meetod sellel CancellationTokenSource'i eksemplaril. Just seda meetodit ma soovitan kasutada. See annab parema kontrolli üle, millal operatsiooni erand võib katkestada.

Kõige äärmuslikum viis lõimede peatamiseks on Win32 API funktsiooni TerminateThread kutsumine. CLR-i käitumine pärast selle funktsiooni väljakutsumist võib olla ettearvamatu. MSDN-s on selle funktsiooni kohta öeldud järgmist: “TerminateThread on ohtlik funktsioon, mida tuleks kasutada ainult kõige äärmuslikumates olukordades.”

Legacy-API muutmine ülesande-põhiseks meetodi FromAsync abil

Kui teil on olnud võimalus töötada projekti kallal, mis algas juba pärast seda, kui ülesanded olid sisse viidud ja enamiku arendajate seas vaikset kohut tekitasid, siis ei pea te tegelema paljude vanade API-dega, olgu need siis kolmandate osapoolte või teie meeskonna varem loodud. Õnneks hoolitses .NET Frameworki arendustiim meie eest, ehkki võib-olla oli nende eesmärgiks enda eest hoolitsemine. Igatahes on .NET-is terve hulk tööriistu, mis võimaldavad valutult ümber kodeerida vana asünkroonse programmeerimise lähenemise uueks. Üks neist on TaskFactory meetod FromAsync. Allpool toodud koodi näitel olen ma vanad asünkroonsed meetodid WebRequest klassist ümber pannud Task'iks 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 sellise asja tegemine sisseehitatud tüüpidega ei ole tõenäoliselt vajalik, kuid iga vana projekt on lihtsalt täis meetodeid BeginDoSomething, mis tagastavad IAsyncResult ja meetodeid EndDoSomething, mis neid vastu võtavad.

Legacy-API muutmine ülesannete põhiseks Task Based lähenemiseks kasutades klassi TaskCompletionSource

Veel üks oluline kaalutav tööriist on klass TaskCompletionSource. Funktsioonide, otstarbe ja tööpõhimõtte poolest võib see meenutada ThreadPooli RegisterWaitForSingleObject meetodit, millest ma eespool rääkisin. Selle klassi abil on lihtne ja mugav vanu asünkroonseid API-sid Task’i-deks ümber muuta.

Ütlete, et ma olen juba rääkinud TaskFactory FromAsync meetodist, mis on nende eesmärkide saavutamiseks mõeldud. Peame meenutama kogu asünkroonsete mudelite arengulugu .net-is, mida Microsoft on viimase 15 aasta jooksul pakkunud: enne Task-Based Asynchronous Pattern (TAP) eksisteeris Asynchronous Programming Pattern (APP), mis keskendus meetoditele. BeginDoSomething, mis tagastab IAsyncResult ja meetoditega EndDoSomething, mis seda aktsepteerib ja noorte pärandi jaoks sobib FromAsync meetod ideaalselt, kuid aja jooksul asendas selle Event Based Asynchronous Pattern (EAP), mis eeldas, et asünkroonse tegevuse lõpetamisel kutsutakse välja sündmus.

TaskCompletionSource sobib suurepäraselt legacy-API-dele, mis on üles ehitatud sündmuste mudelile, pakkumiseks. Selle tööpõhimõte on järgmine: selle klassi objekt omab avalikku omadust, mille tüüp on Task, mille olekut saab hallata läbi meetodite SetResult, SetException jne. TaskCompletionSource klassis. Seal, kus on rakendatud await operaator sellele Task’ile, täidetakse see või tõmmatakse erandiga sõltuvalt TaskCompletionSource meetodist, mida on rakendatud. Kui see pole ikka veel selge, siis vaatame seda koodinäidet, kus mingi vana API EAP ajast pakitakse Task'iks TaskCompletionSource abil: sündmuse korralduse puhul viiakse Task Completed olekusse ja meetod, mis rakendas sellele Task’ile await operaatori, jätkab oma täitmist, saades objekti. tulemus.

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ähis ei ole kaugeltki ainus, mida saab saavutada TaskCompletionSource'i abil. Selle klasi kasutamine avab huvitava võimaluse erinevate API-de projekteerimiseks, mis põhinevad ülesannetel, mis ei kasutata thread'e. Ja nagu me teame, on thread kallis ressurss ning nende arv on piiratud (peamiselt RAM-i mahuga). Seda piirangut on lihtne saavutada, kui arendada näiteks koormatud veebirakendust keerulise äriloogikaga. Vaatame neid võimalusi, millest ma räägin niisuguse triki nagu Long-Polling rakendamisel.

Lühidalt öeldes seisneb trikk selles: peate saama API-lt teavet teatud sündmuste kohta, mis toimuvad tema poolel, kuid mingil põhjusel ei saa API sündmust teatada, vaid saab ainult tagasi anda oleku. Näiteks 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 küsida HTTP serverilt. HTTP server ei saa ise suhtlemist kliendiga algatada. Lihtne lahendus on serveri küsitlemine ajastuse põhjal, kuid see tekitab serverile täiendava koormuse ja lisaviivituse keskmiselt TimerInterval / 2. Selle vältimiseks leiutati trikk, mida nimetatakse pika küsitluse (Long Polling) meetodiks, mis eeldab vastuse viivitust serverist kuni Timeout'i lõppemiseni või sündmuse toimumiseni. Kui sündmus toimub, siis see töödeldakse, kui mitte, siis saadetakse päring uuesti.

while(!eventOccures && !timeoutExceeded)  {

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

Kuid selline lahendus osutub katastroofiliseks, kui oodatavate sündmuste arv kasvab, kuna iga selline klient, kes ootab sündmust, hõivab terve voolu. Lisaks saame me sündmuse toimumise puhul 1 ms lisaviivituse, mis enamasti ei ole märkimisväärne, kuid miks teha tarkvara halvemaks, kui see võiks olla? Kui aga eemaldada Thread.Sleep(1), koormame me kasutu tsükli tõttu ühe protsessorituuma 100% ulatuses, pöörledes asjatult. TaskCompletionSource'i abil saame selle koodi hõlpsasti ümber kirjutada ja lahendada kõik eelpool 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 tootmisvalmis, vaid lihtsalt demo. Reaalsetes olukordades on vajalik veel vähemalt töödelda olukorda, kui sõnum saabus hetkel, mil keegi seda ei oodanud: sellisel juhul peaks meetod AsseptMessageAsync tagastama juba lõpetatud Taski. Kui see olukord on tõesti kõige sagedasem, võib kaaluda ka ValueTaski kasutamist.

Sõnumi päringu saamisel loome ja paneme pingelisse TaskCompletionSource'i ning seejärel ootame, mis juhtub varem: kas määratud ajavahemik aegub või saabub sõnum.

ValueTask: miks ja kuidas

Async/await operaatorid, nagu ka yield return operaator, loovad meetodist olekumasina. See tähendab uue objekti loomist, mis enamasti pole oluline, kuid harvadel juhtudel võib see põhjustada probleeme. Selliseks juhtumiks võib olla meetod, mida tõepoolest sageli kutsutakse — kõne on kümnetest ja sadadest tuhandetest kutsumistest sekundis. Kui selline meetod on kirjutatud nii, et enamikul juhtudel tagastab ta tulemuse, mööda minnes kõigist await meetoditest, siis .NET pakub tööriista selle optimeerimiseks — ValueTask struktuur. Arusaamaks, vaadakem näiteks selle kasutamist: on vahemälu, mida me külastame väga tihti. Mõned väärtused on seal ja siis me lihtsalt tagastame need, kui neid pole, siis läheme aeglase IO poole nende järele. Viimast tahame teha asünkroonselt, seega muutub kogu meetod asünkroonseks. Seega on ilmne variant meetodi kirjutamiseks järgmine:

public async Task GetById(int id) {

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

Soovides veidi optimeerida ja väiksest hirmust selle suhtes, mida Roslyn kompileerides genereerib, saab seda näidet kirjutada järgmiselt:

public Task GetById(int id) {

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

Kuid kõige optimaalsem lahendus on selles olukorras hot-pathi optimeerimine, nimelt väärtuse saamine sõnastikust ilma täiendavate jaotuste ja GC koormuseta, samas kui harvadel juhtudel, kui peab IO-st andmete järele minema, jääb kõik enam-vähem samaks.

public ValueTask GetById(int id) {

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

Vaatame seda koodifragmenti lähemalt: kui väärtus on vahemikus olemas, loome struktuuri, vastasel juhul ümbritsetakse tegelik ülesanne oluliseks. Kutsuv kood ei hooli, millist teed see kood järgnes: ValueTask käitub C# süntaksis samamoodi nagu tavaline Task selles osas.

TaskScheduler'id: Task'ide käivitamisstrateegiate haldamine

Järgmine API, mida sooviksime arutada, on klass TaskScheduler ja selle tuletised. Olen juba varem maininud, et TPL-is on võimalik hallata ülesannete jaotamise strateegiaid voogude vahel. Sellised strateegiad määratletakse TaskScheduleri klassi järglastes. Praktikas leidub praktiliselt igasuguseid strateegiaid, mis võivad olla vajalikud, raamatukogust. ParallelExtensionsExtras, mis on välja töötatud Microsofti poolt, kuid ei ole osa .NET-ist, vaid tarnitakse Nuget paketi kujul. Vaatame kiirelt mõnda neist:

• CurrentThreadTaskScheduler — täidab ülesandeid текущем voos
• LimitedConcurrencyLevelTaskScheduler — piirab samaaegselt täidetavate ülesannete arvu parameetriga N, mille ta konstruktoris vastu võtab.
• OrderedTaskScheduler — määratletakse kui LimitedConcurrencyLevelTaskScheduler(1), seega ülesanded täidetakse järjestikku.
• WorkStealingTaskScheduler — rakendab töövarastamine ülesannete jaotamise lähenemine. Tegelikult on see eraldi ThreadPool. Lahendab probleemi, et .NET ThreadPool on staatiline klass, üks kõigi rakenduste jaoks, mis tähendab, et selle ülekoormamine või vale kasutamine ühe osa programmis võib põhjustada kõrvalmõjusid teises. Veelgi enam, selliste defektide põhjuste mõistmine on äärmiselt keeruline. Seega võib olla vajadus kasutada eraldi WorkStealingTaskScheduler'eid nendes programmi osades, kus ThreadPooli kasutamine võib olla agressiivne ja ettearvamatu.
• QueuedTaskScheduler — võimaldab täita ülesandeid järjekorra reeglitega koos prioriteetidega
• ThreadPerTaskScheduler — loob iga Task jaoks eraldi teema, millega seda täidetakse. Võib olla kasulik ettearvamatult kaua kestvates ülesannetes.

On olemas hea ja üksikasjalik artikkel TaskScheduler'ite kohta Microsofti blogis.

Kõikide Task'idega seotud mugavaks tõrkeotsimiseks Visual Studio's on Tasks aken. Selles aknas saab näha ülesande praegust olekut ja minna üle hetkel täidetavale koodirea.

PLinq ja Parallel klass

Lisaks Task'idele ja kõigile, mis nendega seondub, on .NET-is veel kaks huvitavat tööriista: PLinq (Linq2Parallel) ja Parallel klass. Esimene lubab kõiki Linq operatsioone täita paralleelselt mitmes lõimes. Lõimede arvu saab konfigureerida laiendusena Meetodiga WithDegreeOfParallelism. Kahjuks ei piisa PLinq-lt vaikerežiimis sageli andmeallika sisust oluline kiirusetõus, kuid katse hind on väga madal: piisab, kui kutsuda meetodit AsParallel enne Linq meetodite kettast ja teha jõudluse teste. Veelgi enam, PLinq lubab edastada täiendavat teavet teie andmeallika iseloomu kohta Partitions mehhanismi abil. Täiendavat teavet saab lugeda. siit ja siit.

Statyline Parallel klass pakub meetodeid kollektsiooni Foreach paralleelseks läbimiseks, For tsükli täitmiseks ja mitme delegaadi paralleelseks nõudmiseks. Kogumise praegune voog peatatakse kuni arvutuste lõpetamiseni. Voogude arvu saab konfigureerida, edastades ParallelOptions viimase argumendina. Valikute kaudu saab ka määrata TaskScheduleri ja CancellationTokeni.

Järeldused

Kui ma hakkasin kirjutama seda artiklit oma ettekande materjalidel ja teabel, mida olen kogunud pärast seda, ei oodanud ma, et sellest nii palju tuleb. Nüüd, kui tekstiredaktor, kus ma seda artiklit koostan, ütleb mulle süüdistavalt, et olen jõudnud 15. lehe juurde, teen ma vahekokkuvõtte. Teised nõksud, API, visuaalsed tööriistad ja takistused arutatakse järgmises artiklis.

Järeldused:

• Oluline on tunda tööriistu voogude, asünkroonsuse ja paralleelsuse kasutamiseks, et ära kasutada tänapäevaste arvutite ressursse.
• .NET-is on palju erinevaid tööriistu nende eesmärkide saavutamiseks.
• Kaugel kõik need ei ilmunud korraga, seega võib sageli kohata legacy-lahendusi, kuid on olemas viise vanade API-de transformeerimiseks ilma eriliste pingutusteta.
• Tööde haldamine .NET-is on esitatud klasside Thread ja ThreadPool kaudu
• Meetodid Thread.Abort, Thread.Interrupt ja Win32 API funktsioon TerminateThread on ohtlikud ja nende kasutamist ei soovitata. Nende asemel on soovitatav kasutada CancellationToken'ide mehhanismi.
• Käthread on väärtuslik ressurss, nende arv on piiratud. Tuleb vältida olukordi, kus thread'id ootavad sündmuste toimumist. Selleks on mugav kasutada klassi TaskCompletionSource.
• Kõige võimsamad ja arenenumad tööriistad .NET-is, millega tegeleda paralleelsuse ja asünkroonsete ülesannetega, on Task'id.
• C# async/await operaatorid rakendavad mitteblokeeriva ootamise kontseptsiooni.
• Task'ide jaotust thread'ide vahel saab hallata tüütas TaskScheduler'ist derivaatklassi abil.
• ValueTask struktuur võib olla kasulik hot-paths ja mäluliiklus optimeerimisel.
• Visual Studio Tasks ja Threads aknad pakuvad palju kasulikku teavet, et siluda mitme lõime või asünkroonse koodi.
• PLinq on lahe tööriist, kuid tal ei pruugi olla piisavalt teavet teie andmeallika kohta, küll aga saab seda parandada jaotamise mehhanismi abil.
• Jätkub…

Allikas: habr.com