.NET: ინსტრუმენტები მრავალთრეადინგთან და ასინქრონიასთან მუშაობისთვის. Ნაწილი 1

ვაქვეყნებ ორიგინალურ სტატიას ჰაბრზე, რომლის თარგმანი განთავსებულია კორპორატიულში ბლოგის პოსტი.

რაღაცის ასინქრონულად გაკეთების აუცილებლობა, შედეგის მოლოდინის გარეშე აქ და ახლა, ან დიდი სამუშაოს გაყოფა მის შემსრულებელ რამდენიმე ერთეულზე, არსებობდა კომპიუტერების მოსვლამდე. მათი მოსვლასთან ერთად ეს საჭიროება ძალიან ხელშესახები გახდა. ახლა, 2019 წელს, ამ სტატიას ვბეჭდავ ლეპტოპზე 8-ბირთვიანი Intel Core პროცესორით, რომელზეც ასზე მეტი პროცესი მიმდინარეობს პარალელურად და კიდევ უფრო მეტი თემა. ახლოს არის ცოტა გაფუჭებული ტელეფონი, რამდენიმე წლის წინ ნაყიდი, აქვს 8 ბირთვიანი პროცესორი. თემატური რესურსები სავსეა სტატიებითა და ვიდეოებით, სადაც მათი ავტორები აღფრთოვანებულნი არიან წლევანდელი ფლაგმანი სმარტფონებით, რომლებიც აღჭურვილია 16 ბირთვიანი პროცესორებით. MS Azure გთავაზობთ ვირტუალურ მანქანას 20 ბირთვიანი პროცესორით და 128 TB ოპერატიული მეხსიერებით 2 დოლარზე ნაკლებ ფასად/საათში. სამწუხაროდ, შეუძლებელია მაქსიმუმის მოპოვება და ამ ძალის გამოყენება ძაფების ურთიერთქმედების მართვის გარეშე.

ტერმინოლოგია

პროცესი - OS ობიექტი, იზოლირებული მისამართების სივრცე, შეიცავს ძაფებს.
ძაფი - OS ობიექტი, შესრულების უმცირესი ერთეული, პროცესის ნაწილი, ძაფები იზიარებენ მეხსიერებას და სხვა რესურსებს ერთმანეთთან პროცესის ფარგლებში.
მრავალამომსახურება - OS თვისება, რამდენიმე პროცესის ერთდროულად გაშვების შესაძლებლობა
მრავალბირთვიანი - პროცესორის თვისება, მონაცემთა დამუშავებისთვის რამდენიმე ბირთვის გამოყენების შესაძლებლობა
მრავალპროცესირება - კომპიუტერის თვისება, ფიზიკურად რამდენიმე პროცესორთან ერთდროულად მუშაობის შესაძლებლობა
მრავალძაფიანი — პროცესის თვისება, მონაცემთა დამუშავების რამდენიმე ძაფს შორის განაწილების შესაძლებლობა.
პარალელიზმი - ფიზიკურად ერთდროულად რამდენიმე მოქმედების შესრულება დროის ერთეულზე
ასინქრონულობა - ოპერაციის შესრულება ამ დამუშავების დასრულებამდე მოლოდინის გარეშე; შესრულების შედეგი შეიძლება მოგვიანებით დამუშავდეს.

მეტაფორა

ყველა განმარტება არ არის კარგი და ზოგიერთს დამატებითი ახსნა სჭირდება, ამიტომ ოფიციალურად შემოღებულ ტერმინოლოგიას დავამატებ მეტაფორას საუზმის მომზადების შესახებ. ამ მეტაფორაში საუზმის მომზადება პროცესია.

დილით საუზმის მომზადებისას მე (CPU) მოვდივარ სამზარეულოში (კომპიუტერი). 2 ხელი მაქვს (ბირთვით). სამზარეულოში არის რამდენიმე მოწყობილობა (IO): ღუმელი, ქვაბი, ტოსტერი, მაცივარი. გაზს ვრთავ, ტაფას ვასხამ და გაცხელებას არ ველოდები ზეთს (ასინქრონულად, Non-Blocking-IO-Wait), კვერცხებს გამოვიღებ მაცივრიდან და ვტეხავ თეფშზე, შემდეგ ცალი ხელით ვთქვი (თემა #1), და მეორე (თემა #2) ფირფიტის დაჭერა (გაზიარებული რესურსი). ახლა მინდა ჩავრთო ქვაბი, მაგრამ არ მაქვს საკმარისი ხელები (ძაფის შიმშილი) ამ დროის განმავლობაში ტაფა თბება (შედეგის დამუშავება) რომელშიც ვასხამ ათქვეფილს. ქვაბს ხელს ვკიდებ, ვრთავ და სულელურად ვუყურებ მასში წყლის დუღილს (დაბლოკვა-IO-მოელოდეთ), თუმცა ამ ხნის განმავლობაში მას შეეძლო გაერეცხა თეფში, სადაც ომლეტს ათქვიფდა.

ომლეტი მოვამზადე მხოლოდ 2 ხელით და მეტი არ მაქვს, მაგრამ ამავდროულად ომლეტის ათქვეფის მომენტში ერთდროულად 3 ოპერაცია მოხდა: ომლეტის ათქვეფა, თეფშის დაჭერა, ტაფის გაცხელება. CPU არის კომპიუტერის ყველაზე სწრაფი ნაწილი, IO არის ის, რაც ყველაზე ხშირად ანელებს ყველაფერს, ამიტომ ხშირად ეფექტური გამოსავალია CPU-ს რაღაცით დაკავება IO-დან მონაცემების მიღებისას.

მეტაფორის გაგრძელება:

• თუ ომლეტის მომზადების პროცესში ტანსაცმლის გამოცვლასაც ვცდილობდი, ეს მულტიტასკინგის მაგალითი იქნებოდა. მნიშვნელოვანი ნიუანსი: კომპიუტერები ამაში ბევრად უკეთესები არიან ვიდრე ადამიანები.
• სამზარეულო რამდენიმე შეფ-მზარეულით, მაგალითად რესტორანში - მრავალბირთვიანი კომპიუტერი.
• ბევრი რესტორანი კვების კორტში სავაჭრო ცენტრში - მონაცემთა ცენტრი

.NET Tools

.NET კარგად მუშაობს ძაფებთან, ისევე როგორც ბევრ სხვა რამეში. ყოველი ახალი ვერსიით, ის შემოაქვს უფრო და უფრო ახალ ინსტრუმენტებს მათთან მუშაობისთვის, აბსტრაქციის ახალ ფენებს OS ძაფებზე. აბსტრაქციების კონსტრუქციასთან მუშაობისას, ფრეიმურის დეველოპერები იყენებენ მიდგომას, რომელიც ტოვებს შესაძლებლობას, მაღალი დონის აბსტრაქციის გამოყენებისას, ერთი ან მეტი დონის ქვემოთ ჩასვლა. ყველაზე ხშირად ეს არ არის საჭირო, სინამდვილეში ის ხსნის კარს თოფით ფეხში სროლისთვის, მაგრამ ზოგჯერ, იშვიათ შემთხვევებში, ეს შეიძლება იყოს ერთადერთი გზა პრობლემის გადასაჭრელად, რომელიც არ არის მოგვარებული აბსტრაქციის ამჟამინდელ დონეზე. .

ინსტრუმენტებში ვგულისხმობ როგორც აპლიკაციის პროგრამირების ინტერფეისებს (API), რომლებიც მოწოდებულია ფრეიმიკით და მესამე მხარის პაკეტებით, ასევე მთლიანი პროგრამული გადაწყვეტილებები, რომლებიც ამარტივებს მრავალ ხრახნიან კოდთან დაკავშირებული ნებისმიერი პრობლემის ძიებას.

თემის დაწყება

Thread კლასი არის ყველაზე ძირითადი კლასი .NET-ში თრედებთან მუშაობისთვის. კონსტრუქტორი იღებს ერთ-ერთს ორი დელეგატიდან:

• ThreadStart - პარამეტრების გარეშე
• ParametrizedThreadStart - ტიპის ობიექტის ერთი პარამეტრით.

დელეგატი შესრულდება ახლად შექმნილ თემაში Start მეთოდის გამოძახების შემდეგ. თუ ParametrizedThreadStart ტიპის დელეგატი გადაეცა კონსტრუქტორს, მაშინ ობიექტი უნდა გადაეცეს Start მეთოდს. ეს მექანიზმი საჭიროა ნებისმიერი ადგილობრივი ინფორმაციის ნაკადში გადასატანად. აღსანიშნავია, რომ თემის შექმნა ძვირადღირებული ოპერაციაა და თავად ძაფი მძიმე ობიექტია, თუნდაც იმიტომ, რომ ის 1 მბ მეხსიერებას გამოყოფს სტეკზე და მოითხოვს OS API-სთან ურთიერთქმედებას.

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

ThreadPool კლასი წარმოადგენს აუზის კონცეფციას. .NET-ში, thread pool არის ინჟინერიის ნაწილი და Microsoft-ის დეველოპერებმა დიდი ძალისხმევა დახარჯეს იმისთვის, რომ დარწმუნდნენ, რომ ის ოპტიმალურად მუშაობდა მრავალფეროვან სცენარებში.

ზოგადი კონცეფცია:

აპლიკაციის დაწყების მომენტიდან ის ქმნის რამდენიმე ძაფს რეზერვში ფონზე და იძლევა მათი გამოყენების შესაძლებლობას. თუ ძაფები გამოიყენება ხშირად და დიდი რაოდენობით, აუზი ფართოვდება აბონენტის მოთხოვნილებების დასაკმაყოფილებლად. როდესაც აუზში საჭირო დროს არ არის თავისუფალი ძაფები, ის ან დაელოდება ერთ-ერთი ძაფების დაბრუნებას, ან შექმნის ახალს. აქედან გამომდინარეობს, რომ ძაფების ფონდი შესანიშნავია ზოგიერთი მოკლევადიანი მოქმედებისთვის და ცუდად შეეფერება ოპერაციებს, რომლებიც მუშაობს როგორც სერვისები აპლიკაციის მთელი მუშაობის განმავლობაში.

აუზიდან ნაკადის გამოსაყენებლად არის QueueUserWorkItem მეთოდი, რომელიც იღებს WaitCallback ტიპის დელეგატს, რომელსაც აქვს იგივე ხელმოწერა, როგორც ParametrizedThreadStart და მასზე გადაცემული პარამეტრი ასრულებს იგივე ფუნქციას.

ThreadPool.QueueUserWorkItem(...);

ნაკლებად ცნობილი thread pool მეთოდი RegisterWaitForSingleObject გამოიყენება არადაბლოკვის IO ოპერაციების ორგანიზებისთვის. ამ მეთოდზე გადაცემული დელეგატი გამოიძახება, როდესაც მეთოდზე გადაცემული WaitHandle იქნება „გამოშვებული“.

ThreadPool.RegisterWaitForSingleObject(...)

.NET-ს აქვს ნაკადის ტაიმერი და ის განსხვავდება WinForms/WPF ტაიმერებისგან იმით, რომ მისი დამმუშავებელი გამოიძახება აუზიდან აღებულ ძაფზე.

System.Threading.Timer

ასევე არსებობს საკმაოდ ეგზოტიკური გზა დელეგატის შესასრულებლად ძაფზე გასაგზავნად აუზიდან - BeginInvoke მეთოდი.

DelegateInstance.BeginInvoke

მინდა მოკლედ ვისაუბრო იმ ფუნქციაზე, რომელსაც შეიძლება ეწოდოს მრავალი ზემოაღნიშნული მეთოდი - CreateThread from Kernel32.dll Win32 API. არსებობს გზა, გარე მეთოდების მექანიზმის წყალობით, რომ გამოიძახოთ ეს ფუნქცია. ასეთი ზარი მე მხოლოდ ერთხელ მინახავს მემკვიდრეობის კოდის საშინელ მაგალითში და ავტორის მოტივაცია, რომელმაც ზუსტად ეს გააკეთა, დღემდე საიდუმლოდ რჩება ჩემთვის.

Kernel32.dll CreateThread

თემების ნახვა და გამართვა

თქვენ მიერ შექმნილი ძაფები, მესამე მხარის ყველა კომპონენტი და .NET ფონდი შეგიძლიათ ნახოთ Visual Studio-ის Threads ფანჯარაში. ამ ფანჯარაში ნაჩვენები იქნება თემის ინფორმაცია მხოლოდ მაშინ, როდესაც აპლიკაცია გამართვის პროცესშია და Break რეჟიმშია. აქ შეგიძლიათ მოხერხებულად ნახოთ დატის სახელები და პრიორიტეტები თითოეული თემის, და გადართოთ გამართვა კონკრეტულ თემაზე. Thread კლასის Priority თვისების გამოყენებით, შეგიძლიათ დააყენოთ ძაფების პრიორიტეტი, რომელსაც OC და CLR აღიქვამენ როგორც რეკომენდაციას პროცესორის დროის ძაფებს შორის გაყოფისას.

ამოცანების პარალელური ბიბლიოთეკა

სამუშაო პარალელური ბიბლიოთეკა (TPL) დაინერგა .NET 4.0-ში. ახლა ის არის ასინქრონიასთან მუშაობის სტანდარტული და მთავარი ინსტრუმენტი. ნებისმიერი კოდი, რომელიც იყენებს უფრო ძველ მიდგომას, ითვლება მემკვიდრეობით. TPL-ის ძირითადი ერთეულია Task კლასი System.Threading.Tasks სახელების სივრციდან. ამოცანა არის აბსტრაქცია ძაფზე. C# ენის ახალი ვერსიით, ჩვენ მივიღეთ Tasks-თან მუშაობის ელეგანტური გზა - async/wait ოპერატორები. ამ ცნებებმა შესაძლებელი გახადა ასინქრონული კოდის დაწერა, თითქოს ის მარტივი და სინქრონული ყოფილიყო, ამან კი საშუალება მისცა ადამიანებს, რომლებსაც ნაკლებად ესმით ძაფების შიდა ფუნქციონირება, დაეწერათ პროგრამები, რომლებიც იყენებენ მათ, აპლიკაციები, რომლებიც არ იყინება ხანგრძლივი ოპერაციების შესრულებისას. ასინქრონიზაციის/მოლოდინის გამოყენება არის ერთი ან თუნდაც რამდენიმე სტატიის თემა, მაგრამ მე შევეცდები რამდენიმე წინადადებით გავიგო მისი არსი:

• async არის მეთოდის მოდიფიკატორი, რომელიც აბრუნებს ამოცანას ან void-ს
• და await არის დაუბლოკავი Task ლოდინის ოპერატორი.

კიდევ ერთხელ: მოლოდინის ოპერატორი, ზოგად შემთხვევაში (არსებობს გამონაკლისები), გაათავისუფლებს შესრულების მიმდინარე ძაფს შემდგომში, და როდესაც დავალება დაასრულებს შესრულებას და თემას (ფაქტობრივად, უფრო სწორი იქნება კონტექსტის თქმა , მაგრამ ამის შესახებ მოგვიანებით) გააგრძელებს მეთოდის შესრულებას შემდგომში. .NET-ის შიგნით, ეს მექანიზმი დანერგილია ისევე, როგორც yield return, როდესაც დაწერილი მეთოდი გადაიქცევა მთელ კლასად, რომელიც არის სახელმწიფო მანქანა და შეიძლება შესრულდეს ცალკეულ ნაწილებად, ამ მდგომარეობიდან გამომდინარე. ნებისმიერ მსურველს შეუძლია დაწეროს ნებისმიერი მარტივი კოდი asynс/wait-ის გამოყენებით, შეადგინოს და ნახოს ასამბლეა JetBrains dotPeek-ის გამოყენებით Compiler Generated Code-ით ჩართული.

მოდით შევხედოთ Task-ის გაშვებისა და გამოყენების ვარიანტებს. ქვემოთ მოცემულ კოდის მაგალითში, ჩვენ ვქმნით ახალ ამოცანას, რომელიც არაფერს აკეთებს სასარგებლო (Thread.Sleep(10000)), მაგრამ რეალურ ცხოვრებაში ეს უნდა იყოს რთული პროცესორის ინტენსიური სამუშაო.

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
}

Task იქმნება რამდენიმე ვარიანტით:

• LongRunning არის მინიშნება იმისა, რომ დავალება სწრაფად არ შესრულდება, რაც იმას ნიშნავს, რომ შეიძლება ღირდეს იმის გათვალისწინება, რომ არ აიღოთ თემა აუზიდან, არამედ შექმნათ ცალკე ამ ამოცანისთვის, რათა არ დააზიანოთ სხვები.
• AttachedToParent - ამოცანები შეიძლება განლაგდეს იერარქიაში. თუ ეს ვარიანტი იქნა გამოყენებული, მაშინ ამოცანა შეიძლება იყოს ისეთ მდგომარეობაში, სადაც ის თავად დაასრულა და ელოდება შვილების აღსრულებას.
• PreferFairness - ნიშნავს, რომ უკეთესი იქნებოდა შესასრულებლად გაგზავნილი ამოცანები უფრო ადრე შეასრულოთ, ვიდრე მოგვიანებით გაგზავნილნი. მაგრამ ეს მხოლოდ რეკომენდაციაა და შედეგი არ არის გარანტირებული.

მეთოდისთვის გადაცემული მეორე პარამეტრი არის CancellationToken. ოპერაციის გაუქმების სწორად დასამუშავებლად მისი დაწყების შემდეგ, შესრულებული კოდი უნდა იყოს შევსებული ჩეკებით CancellationToken მდგომარეობისთვის. თუ შემოწმებები არ არის, მაშინ CancellationTokenSource ობიექტზე გამოძახებული Cancel მეთოდი შეძლებს შეაჩეროს დავალების შესრულება მხოლოდ მის დაწყებამდე.

ბოლო პარამეტრი არის TaskScheduler ტიპის გრაფიკის ობიექტი. ეს კლასი და მისი შთამომავლები შექმნილია იმისთვის, რომ გააკონტროლონ ამოცანების ძაფებში განაწილების სტრატეგიები; ნაგულისხმევად, Task შესრულდება შემთხვევით ძაფზე აუზიდან.

მოლოდინის ოპერატორი გამოიყენება შექმნილ Task-ზე, რაც ნიშნავს, რომ მის შემდეგ დაწერილი კოდი, თუ არის ასეთი, შესრულდება იმავე კონტექსტში (ხშირად ეს ნიშნავს იმავე ძაფზე), როგორც კოდი მოლოდინამდე.

მეთოდი მონიშნულია, როგორც async void, რაც ნიშნავს, რომ მას შეუძლია გამოიყენოს მოლოდინის ოპერატორი, მაგრამ დარეკვის კოდი ვერ დაელოდება შესრულებას. თუ ასეთი ფუნქცია აუცილებელია, მაშინ მეთოდმა უნდა დააბრუნოს Task. მეთოდები, რომლებიც აღინიშნება async void საკმაოდ გავრცელებულია: როგორც წესი, ეს არის მოვლენების დამმუშავებლები ან სხვა მეთოდები, რომლებიც მუშაობენ ცეცხლზე და ივიწყებენ პრინციპს. თუ თქვენ გჭირდებათ არა მხოლოდ შესაძლებლობა დაელოდოთ შესრულების დასრულებას, არამედ დააბრუნოთ შედეგი, მაშინ უნდა გამოიყენოთ Task.

დავალებაზე, რომელიც StartNew მეთოდმა დააბრუნა, ისევე როგორც ნებისმიერ სხვაზე, შეგიძლიათ გამოძახოთ ConfigureAwait მეთოდი ცრუ პარამეტრით, შემდეგ შესრულება ლოდინის შემდეგ გაგრძელდება არა გადაღებულ კონტექსტზე, არამედ თვითნებურზე. ეს ყოველთვის უნდა გაკეთდეს, როდესაც შესრულების კონტექსტი არ არის მნიშვნელოვანი კოდისთვის მოლოდინის შემდეგ. ეს არის ასევე MS-ის რეკომენდაცია კოდის დაწერისას, რომელიც მიწოდებული იქნება შეფუთული ბიბლიოთეკაში.

მოდით ცოტა მეტი ვისაუბროთ იმაზე, თუ როგორ შეგიძლიათ დაელოდოთ დავალების დასრულებას. ქვემოთ მოცემულია კოდის მაგალითი, კომენტარებით, როდის კეთდება მოლოდინი პირობითად კარგად და როდის კეთდება პირობითად ცუდად.

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // good

    result = AsyncMethod().Result; // bad

    AsyncMethod().Wait(); // bad

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

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

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

პირველ მაგალითში, ჩვენ ველოდებით დავალების დასრულებას გამოძახების თემის დაბლოკვის გარეშე; ჩვენ ვუბრუნდებით შედეგის დამუშავებას მხოლოდ მაშინ, როდესაც ის უკვე არსებობს; მანამდე კი, გამოძახების თემა რჩება საკუთარ მოწყობილობაზე.

მეორე ვარიანტში ვბლოკავთ გამოძახების ძაფს, სანამ არ გამოითვლება მეთოდის შედეგი. ეს ცუდია არა მხოლოდ იმიტომ, რომ ჩვენ დავიკავეთ თემა, პროგრამის ასეთი ღირებული რესურსი, მარტივი უსაქმურობით, არამედ იმიტომაც, რომ თუ მეთოდის კოდი, რომელსაც ჩვენ ვუწოდებთ, შეიცავს მოლოდინს და სინქრონიზაციის კონტექსტი მოითხოვს გამოძახების თემაში დაბრუნებას შემდეგ. დაველოდოთ, მაშინ მივიღებთ ჩიხს: გამომძახებელი ძაფი ელოდება ასინქრონული მეთოდის შედეგის გამოთვლას, ასინქრონული მეთოდი ამაოდ ცდილობს განაგრძოს მისი შესრულება გამოძახებულ ძაფში.

ამ მიდგომის კიდევ ერთი მინუსი არის შეცდომების რთული დამუშავება. ფაქტია, რომ ასინქრონულ კოდში შეცდომებს async/wait-ის გამოყენებისას ძალიან მარტივია დამუშავება - ისინი ისე იქცევიან, თითქოს კოდი სინქრონული იყოს. მიუხედავად იმისა, რომ თუ ჩვენ გამოვიყენებთ სინქრონულ ლოდინის ეგზორციზმს ამოცანაზე, საწყისი გამონაკლისი გადაიქცევა AggregateException, ე.ი. გამონაკლისების მოსაგვარებლად, თქვენ მოგიწევთ შეამოწმოთ InnerException ტიპი და ჩაწეროთ if ჯაჭვი ერთ catch ბლოკში ან გამოიყენოთ catch კონსტრუქციისას, ნაცვლად catch ბლოკების ჯაჭვისა, რომელიც უფრო ცნობილია C# სამყაროში.

მესამე და ბოლო მაგალითები ასევე მონიშნულია ცუდად იმავე მიზეზით და შეიცავს ყველა იგივე პრობლემას.

WhenAny და WhenAll მეთოდები უკიდურესად მოსახერხებელია ამოცანების ჯგუფის მოლოდინში; ისინი ახვევენ ამოცანების ჯგუფს ერთში, რომელიც გააქტიურდება ან როდესაც ჯგუფიდან Task პირველად გააქტიურდება, ან როდესაც ყველა მათგანი დაასრულებს შესრულებას.

ძაფების გაჩერება

სხვადასხვა მიზეზის გამო შესაძლოა საჭირო გახდეს ნაკადის შეჩერება მისი დაწყების შემდეგ. ამის გაკეთების რამდენიმე გზა არსებობს. Thread კლასს აქვს ორი სათანადოდ დასახელებული მეთოდი: Გაუქმება и შეუშალოს. პირველი არ არის რეკომენდებული გამოსაყენებლად, რადგან ნებისმიერ შემთხვევით მომენტში დარეკვის შემდეგ, ნებისმიერი ინსტრუქციის დამუშავების დროს, გამონაკლისი იქნება დაშვებული ThreadAbortedException. თქვენ არ ელით, რომ ასეთი გამონაკლისი იქნება ნებისმიერი მთელი რიცხვის ცვლადის გაზრდისას, არა? და ამ მეთოდის გამოყენებისას, ეს ძალიან რეალური სიტუაციაა. თუ გჭირდებათ CLR-ის მიერ ასეთი გამონაკლისის წარმოქმნის თავიდან აცილება კოდის გარკვეულ მონაკვეთში, შეგიძლიათ გადაიტანოთ ის ზარებში. თემა.BeginCriticalRegion, თემა.EndCriticalRegion. საბოლოო ბლოკში ჩაწერილი ნებისმიერი კოდი შეფუთულია ასეთ ზარებში. ამ მიზეზით, ჩარჩო კოდის სიღრმეში შეგიძლიათ იპოვოთ ბლოკები ცარიელი ლელოთი, მაგრამ არა ცარიელი საბოლოოდ. მაიკროსოფტი იმდენად უარყოფს ამ მეთოდს, რომ არ ჩართეს იგი .net core-ში.

შეფერხების მეთოდი უფრო პროგნოზირებად მუშაობს. მას შეუძლია შეწყვიტოს თემა გამონაკლისის გარდა ThreadInterruptedException მხოლოდ იმ მომენტებში, როდესაც ძაფი მოლოდინის მდგომარეობაშია. ის ამ მდგომარეობაში შედის დაკიდებისას WaitHandle-ის მოლოდინში, ჩაკეტვისას ან Thread.Sleep-ის დარეკვის შემდეგ.

ზემოთ აღწერილი ორივე ვარიანტი ცუდია, რადგან ისინი არაპროგნოზირებადია. გამოსავალი არის სტრუქტურის გამოყენება CancellationToken და კლასი CancellationTokenSource. საქმე ისაა: იქმნება CancellationTokenSource კლასის ეგზემპლარი და მხოლოდ მას, ვინც მას ფლობს, შეუძლია შეაჩეროს ოპერაცია მეთოდის გამოძახებით. გაუქმება. მხოლოდ CancellationToken გადაეცემა თავად ოპერაციას. CancellationToken-ის მფლობელებს არ შეუძლიათ თავად გააუქმონ ოპერაცია, მაგრამ შეუძლიათ მხოლოდ შეამოწმონ გაუქმდა თუ არა ოპერაცია. ამისთვის არის ლოგიკური თვისება მოთხოვნილია გაუქმება და მეთოდი ThrowIfCancelRequested. ეს უკანასკნელი გამონაკლისს დააყენებს TaskCancelledException თუ Cancel მეთოდი გამოიძახებოდა CancellationToken ეგზემპლარზე თუთიყუშში. და ეს არის მეთოდი, რომელსაც გირჩევთ გამოიყენოთ. ეს არის გაუმჯობესება წინა ვარიანტებთან შედარებით სრული კონტროლის მოპოვებით, თუ რა მომენტში შეიძლება შეწყდეს გამონაკლისის ოპერაცია.

თემის შეჩერების ყველაზე სასტიკი ვარიანტია Win32 API TerminateThread ფუნქციის გამოძახება. CLR-ის ქცევა ამ ფუნქციის გამოძახების შემდეგ შეიძლება არაპროგნოზირებადი იყოს. MSDN-ზე შემდეგი წერია ამ ფუნქციის შესახებ: ”TerminateThread არის საშიში ფუნქცია, რომელიც უნდა იქნას გამოყენებული მხოლოდ ყველაზე ექსტრემალურ შემთხვევებში. "

მოძველებული API-ის გადაყვანა Task Based-ად FromAsync მეთოდის გამოყენებით

თუ თქვენ გაგიმართლათ იმუშაოთ პროექტზე, რომელიც დაიწყო Tasks-ის დანერგვის შემდეგ და შეწყვიტა დეველოპერების უმეტესობისთვის მშვიდი საშინელება, მაშინ არ მოგიწევთ საქმე უამრავ ძველ API-სთან, როგორც მესამე მხარის, ასევე თქვენს გუნდთან. წარსულში აწამა. საბედნიეროდ, .NET Framework-ის გუნდმა იზრუნა ჩვენზე, თუმცა შესაძლოა მიზანი იყო საკუთარ თავზე ზრუნვა. როგორც არ უნდა იყოს, .NET-ს აქვს მრავალი ინსტრუმენტი ძველი ასინქრონული პროგრამირების მიდგომებით დაწერილი კოდის უმტკივნეულოდ კონვერტაციისთვის ახალზე. ერთ-ერთი მათგანია TaskFactory-ის FromAsync მეთოდი. ქვემოთ მოცემულ კოდის მაგალითში, ამ მეთოდის გამოყენებით მე ვახვევ 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. ფუნქციების, მიზნისა და მოქმედების პრინციპის თვალსაზრისით, ის შეიძლება გარკვეულწილად მოგაგონებთ ThreadPool კლასის RegisterWaitForSingleObject მეთოდს, რომლის შესახებაც ზემოთ დავწერე. ამ კლასის გამოყენებით, თქვენ შეგიძლიათ მარტივად და მოხერხებულად გადაიტანოთ ძველი ასინქრონული API-ები Tasks-ში.

თქვენ იტყვით, რომ მე უკვე ვისაუბრე ამ მიზნებისათვის განკუთვნილი TaskFactory კლასის FromAsync მეთოდზე. აქ ჩვენ მოგვიწევს გავიხსენოთ .net-ში ასინქრონული მოდელების განვითარების მთელი ისტორია, რომელსაც Microsoft გვთავაზობდა ბოლო 15 წლის განმავლობაში: Task-Based Asynchronous Pattern (TAP), იყო ასინქრონული პროგრამირების ნიმუში (APP), რომელიც. მეთოდებს ეხებოდა დასაწყისიDoSomething ბრუნდება IAsync შედეგი და მეთოდები დასასრულიDoSomething, რომელიც იღებს მას და ამ წლების მემკვიდრეობისთვის FromAsync მეთოდი უბრალოდ სრულყოფილია, მაგრამ დროთა განმავლობაში ის შეიცვალა მოვლენებზე დაფუძნებული ასინქრონული ნიმუშით (აღმოსავლეთ პარტნიორობის), რომელიც ვარაუდობდა, რომ მოვლენა წამოიჭრებოდა ასინქრონული ოპერაციის დასრულებისას.

TaskCompletionSource შესანიშნავია ღონისძიების მოდელის გარშემო აგებული Tasks და მემკვიდრეობითი API-ების შესაფუთად. მისი მუშაობის არსი შემდეგია: ამ კლასის ობიექტს აქვს Task ტიპის საჯარო თვისება, რომლის მდგომარეობის კონტროლი შესაძლებელია TaskCompletionSource კლასის SetResult, SetException და ა.შ. მეთოდებით. იმ ადგილებში, სადაც მოლოდინის ოპერატორი იქნა გამოყენებული ამ ამოცანაზე, ის შესრულდება ან წარუმატებელი იქნება გამონაკლისით, დამოკიდებულია TaskCompletionSource-ზე გამოყენებული მეთოდის მიხედვით. თუ ეს ჯერ კიდევ გაუგებარია, მოდით შევხედოთ ამ კოდის მაგალითს, სადაც ზოგიერთი ძველი EAP API შეფუთულია Task-ში TaskCompletionSource-ის გამოყენებით: მოვლენის გააქტიურებისას, Task გადავა დასრულებულ მდგომარეობაში და მეთოდი, რომელიც გამოიყენებდა მოლოდინ ოპერატორს. ამ ამოცანას განაახლებს მისი შესრულება ობიექტის მიღების შემდეგ შედეგად.

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-ების დიზაინის საინტერესო შესაძლებლობას Tasks-ზე, რომლებიც არ იკავებენ ძაფებს. ნაკადი კი, როგორც გვახსოვს, ძვირადღირებული რესურსია და მათი რაოდენობა შეზღუდულია (ძირითადად ოპერატიული მეხსიერების მოცულობით). ეს შეზღუდვა ადვილად მიიღწევა, მაგალითად, დატვირთული ვებ აპლიკაციის შემუშავებით, რთული ბიზნეს ლოგიკით. მოდით განვიხილოთ ის შესაძლებლობები, რომლებზეც მე ვსაუბრობ ისეთი ხრიკის განხორციელებისას, როგორიცაა Long-Polling.

მოკლედ, ხრიკის არსი ასეთია: თქვენ უნდა მიიღოთ ინფორმაცია API-დან მის მხარეზე მომხდარი ზოგიერთი მოვლენის შესახებ, ხოლო API, რატომღაც, ვერ აცნობებს მოვლენას, მაგრამ შეუძლია მხოლოდ მდგომარეობის დაბრუნება. ამის მაგალითია ყველა API, რომელიც აშენებულია HTTP-ზე WebSocket-ის დრომდე ან როცა რაიმე მიზეზით შეუძლებელი იყო ამ ტექნოლოგიის გამოყენება. კლიენტს შეუძლია ჰკითხოს HTTP სერვერს. HTTP სერვერს თავად არ შეუძლია კლიენტთან კომუნიკაციის დაწყება. მარტივი გამოსავალი არის სერვერის გამოკითხვა ტაიმერის გამოყენებით, მაგრამ ეს ქმნის დამატებით დატვირთვას სერვერზე და დამატებით დაყოვნებას საშუალოდ TimerInterval / 2. ამის თავიდან ასაცილებლად გამოიგონეს ხრიკი სახელწოდებით Long Polling, რომელიც გულისხმობს პასუხის დაგვიანებას. სერვერზე, სანამ ვადა ამოიწურება ან მოხდება მოვლენა. თუ მოვლენა მოხდა, მაშინ ის მუშავდება, თუ არა, მაშინ მოთხოვნა ხელახლა იგზავნება.

while(!eventOccures && !timeoutExceeded)  {

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

მაგრამ ასეთი გამოსავალი საშინელება აღმოჩნდება, როგორც კი მოვლენის მოლოდინში კლიენტების რაოდენობა გაიზრდება, რადგან... ყოველი ასეთი კლიენტი იკავებს მთელ თემას მოვლენის მოლოდინში. დიახ, და ჩვენ ვიღებთ დამატებით 1 ms დაგვიანებას მოვლენის გაშვებისას, ყველაზე ხშირად ეს არ არის მნიშვნელოვანი, მაგრამ რატომ ვაქცევთ პროგრამულ უზრუნველყოფას უარესად, ვიდრე ეს შეიძლება იყოს? თუ 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 მეთოდმა უნდა დააბრუნოს უკვე დასრულებული Task. თუ ეს ყველაზე გავრცელებული შემთხვევაა, მაშინ შეგიძლიათ იფიქროთ ValueTask-ის გამოყენებაზე.

როდესაც ვიღებთ თხოვნას შეტყობინებაზე, ვქმნით და ვათავსებთ TaskCompletionSource-ს ლექსიკონში და შემდეგ ველოდებით რა მოხდება პირველ რიგში: ამოიწურება მითითებული დროის ინტერვალი ან მიიღება შეტყობინება.

ValueTask: რატომ და როგორ

async/wait ოპერატორები, ისევე როგორც yield return ოპერატორი, აგენერირებენ მდგომარეობის მანქანას მეთოდიდან და ეს არის ახალი ობიექტის შექმნა, რომელიც თითქმის ყოველთვის არ არის მნიშვნელოვანი, მაგრამ იშვიათ შემთხვევებში მას შეუძლია შექმნას პრობლემა. ეს შემთხვევა შეიძლება იყოს მეთოდი, რომელსაც ნამდვილად ხშირად უწოდებენ, ჩვენ ვსაუბრობთ ათეულ და ასეულ ათასობით ზარზე წამში. თუ ასეთი მეთოდი ისეა დაწერილი, რომ უმეტეს შემთხვევაში აბრუნებს შედეგს ყველა მოლოდინის მეთოდის გვერდის ავლით, მაშინ .NET უზრუნველყოფს ამის ოპტიმიზაციის ინსტრუმენტს - ValueTask სტრუქტურას. გასაგებად, მოდით შევხედოთ მისი გამოყენების მაგალითს: არის ქეში, რომელსაც ძალიან ხშირად მივდივართ. მასში არის გარკვეული მნიშვნელობები და შემდეგ ჩვენ უბრალოდ ვაბრუნებთ მათ; თუ არა, მაშინ მივდივართ ზოგიერთ ნელ IO-ზე მათ მისაღებად. მე მინდა გავაკეთო ეს უკანასკნელი ასინქრონულად, რაც ნიშნავს, რომ მთელი მეთოდი აღმოჩნდება ასინქრონული. ამრიგად, მეთოდის დაწერის აშკარა გზა შემდეგია:

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

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

ცოტა ოპტიმიზაციის სურვილის და მცირედი შიშის გამო, თუ რას გამოიმუშავებს როსლინი ამ კოდის შედგენისას, შეგიძლიათ გადაწეროთ ეს მაგალითი შემდეგნაირად:

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# სინტაქსის თვალსაზრისით, იქცევა ისევე, როგორც ჩვეულებრივი Task ამ შემთხვევაში.

TaskSchedulers: დავალების გაშვების სტრატეგიების მართვა

შემდეგი API, რომელიც მინდა განვიხილო, არის კლასი TaskScheduler და მისი წარმოებულები. ზემოთ უკვე აღვნიშნე, რომ TPL-ს აქვს უნარი მართოს სტრატეგიები ძაფებში Tasks-ის განაწილებისთვის. ასეთი სტრატეგიები განსაზღვრულია TaskScheduler კლასის შთამომავლებში. თითქმის ნებისმიერი სტრატეგია, რომელიც შეიძლება დაგჭირდეთ, შეგიძლიათ იპოვოთ ბიბლიოთეკაში. Parallel ExtensionsExtras, შემუშავებული Microsoft-ის მიერ, მაგრამ არა .NET-ის ნაწილი, მაგრამ მოწოდებულია Nuget პაკეტის სახით. მოკლედ გადავხედოთ ზოგიერთ მათგანს:

• CurrentThreadTaskScheduler — ასრულებს Tasks მიმდინარე თემაში
• LimitedConcurrencyLevelTaskScheduler — ზღუდავს ერთდროულად შესრულებულ ამოცანების რაოდენობას N პარამეტრით, რომელიც მიღებულია კონსტრუქტორში
• OrderedTaskScheduler — განისაზღვრება, როგორც LimitedConcurrencyLevelTaskScheduler(1), ამიტომ დავალებები შესრულდება თანმიმდევრობით.
• WorkStealingTaskScheduler - ახორციელებს სამუშაოს ქურდობა ამოცანების განაწილების მიდგომა. არსებითად, ეს არის ცალკე ThreadPool. წყვეტს პრობლემას, რომ .NET ThreadPool-ში არის სტატიკური კლასი, ერთი ყველა აპლიკაციისთვის, რაც ნიშნავს, რომ პროგრამის ერთ ნაწილში მისმა გადატვირთვამ ან არასწორმა გამოყენებამ შეიძლება გამოიწვიოს გვერდითი მოვლენები მეორეში. უფრო მეტიც, უკიდურესად რთულია ამგვარი დეფექტების მიზეზის გაგება. რომ. შესაძლოა საჭირო გახდეს ცალკე WorkStealingTaskScheduler-ის გამოყენება პროგრამის ნაწილებში, სადაც ThreadPool-ის გამოყენება შეიძლება იყოს აგრესიული და არაპროგნოზირებადი.
• QueuedTaskScheduler — საშუალებას გაძლევთ შეასრულოთ დავალებები პრიორიტეტული რიგის წესების მიხედვით
• ThreadPerTaskScheduler — ქმნის ცალკე თემას ყოველი ამოცანისთვის, რომელიც შესრულებულია მასზე. შეიძლება სასარგებლო იყოს ამოცანებისთვის, რომელთა შესრულებასაც არაპროგნოზირებად დიდი დრო სჭირდება.

არის კარგი დეტალი სტატიის TaskScheduler-ის შესახებ microsoft ბლოგზე.

Tasks-თან დაკავშირებული ყველაფრის მოსახერხებელი გამართვისთვის, Visual Studio-ს აქვს Tasks ფანჯარა. ამ ფანჯარაში შეგიძლიათ იხილოთ ამოცანის მიმდინარე მდგომარეობა და გადახვიდეთ კოდის ამჟამად შემსრულებელ ხაზზე.

PLinq და პარალელური კლასი

Tasks-ისა და მათ შესახებ ნათქვამის გარდა, .NET-ში არის კიდევ ორი ​​საინტერესო ინსტრუმენტი: PLinq (Linq2Parallel) და Parallel კლასი. პირველი გვპირდება ყველა Linq ოპერაციების პარალელურ შესრულებას მრავალ ძაფზე. ძაფების რაოდენობის კონფიგურაცია შესაძლებელია WithDegreeOfParallelism გაფართოების მეთოდის გამოყენებით. სამწუხაროდ, ყველაზე ხშირად PLinq-ს ნაგულისხმევ რეჟიმში არ აქვს საკმარისი ინფორმაცია თქვენი მონაცემთა წყაროს შიდა ნაწილების შესახებ, რათა უზრუნველყოს მნიშვნელოვანი სიჩქარის მომატება, მეორეს მხრივ, მცდელობის ღირებულება ძალიან დაბალია: თქვენ უბრალოდ უნდა გამოიძახოთ AsParallel მეთოდი. Linq მეთოდების ჯაჭვი და შესრულების ტესტები. გარდა ამისა, შესაძლებელია PLinq-ს დამატებითი ინფორმაციის გადაცემა თქვენი მონაცემთა წყაროს ბუნების შესახებ Partitions მექანიზმის გამოყენებით. შეგიძლიათ მეტი წაიკითხოთ აქ и აქ.

Parallel სტატიკური კლასი უზრუნველყოფს მეთოდებს Foreach-ის კოლექციის პარალელურად გამეორებისთვის, For მარყუჟის შესასრულებლად და რამდენიმე დელეგატის პარალელურად Invoke-ის შესასრულებლად. მიმდინარე თემის შესრულება შეჩერდება გამოთვლების დასრულებამდე. ძაფების რაოდენობის კონფიგურაცია შესაძლებელია ბოლო არგუმენტად ParallelOptions-ის გადაცემით. თქვენ ასევე შეგიძლიათ მიუთითოთ TaskScheduler და CancellationToken პარამეტრების გამოყენებით.

დასკვნები

როდესაც დავიწყე ამ სტატიის წერა ჩემი მოხსენების მასალებზე და მის შემდგომ მუშაობის დროს შეგროვებული ინფორმაციის საფუძველზე, არ ველოდი, რომ ამდენი იქნებოდა. ახლა, როდესაც ტექსტის რედაქტორი, რომელშიც მე ვბეჭდავ ამ სტატიას საყვედურით მეტყვის, რომ მე-15 გვერდი წავიდა, მე შევაჯამებ შუალედურ შედეგებს. სხვა ხრიკებს, API-ებს, ვიზუალურ ინსტრუმენტებს და ხრიკებს განიხილავს შემდეგ სტატიაში.

დასკვნები:

• თქვენ უნდა იცოდეთ ძაფებთან მუშაობის ინსტრუმენტები, ასინქრონულობა და პარალელიზმი, რათა გამოიყენოთ თანამედროვე კომპიუტერების რესურსები.
• .NET-ს აქვს მრავალი განსხვავებული ინსტრუმენტი ამ მიზნებისათვის
• ყველა მათგანი ერთდროულად არ გამოჩნდა, ასე რომ, ხშირად შეგიძლიათ იპოვოთ მემკვიდრეობითი, თუმცა, არსებობს ძველი API-ების გარდაქმნის გზები დიდი ძალისხმევის გარეშე.
• .NET-ში ძაფებთან მუშაობა წარმოდგენილია Thread და ThreadPool კლასებით
• Thread.Abort, Thread.Interrupt და Win32 API TerminateThread მეთოდები საშიშია და არ არის რეკომენდებული გამოსაყენებლად. ამის ნაცვლად, უმჯობესია გამოიყენოთ CancellationToken მექანიზმი
• ნაკადი ღირებული რესურსია და მისი მიწოდება შეზღუდულია. თავიდან უნდა იქნას აცილებული სიტუაციები, სადაც თემა არის დაკავებული მოვლენების მოლოდინში. ამისთვის მოსახერხებელია TaskCompletionSource კლასის გამოყენება
• ყველაზე ძლიერი და მოწინავე .NET ინსტრუმენტები პარალელიზმთან და ასინქრონიასთან მუშაობისთვის არის Tasks.
• c# async/wait ოპერატორები ახორციელებენ არადაბლოკვის ლოდინის კონცეფციას
• თქვენ შეგიძლიათ აკონტროლოთ Tasks-ის განაწილება ძაფებში, TaskScheduler-ისგან მიღებული კლასების გამოყენებით
• ValueTask სტრუქტურა შეიძლება სასარგებლო იყოს ცხელი გზებისა და მეხსიერების ტრაფიკის ოპტიმიზაციისთვის
• Visual Studio-ის Tasks და Threads ფანჯრები გთავაზობთ უამრავ ინფორმაციას, რომელიც სასარგებლოა მრავალ ნაკადიანი ან ასინქრონული კოდის გამართვისთვის.
• PLinq მაგარი ინსტრუმენტია, მაგრამ მას შეიძლება არ ჰქონდეს საკმარისი ინფორმაცია თქვენი მონაცემთა წყაროს შესახებ, მაგრამ ამის გამოსწორება შესაძლებელია დანაყოფის მექანიზმის გამოყენებით
• გაგრძელება იქნება ...

წყარო: www.habr.com