🥇.NET៖ ឧបករណ៍សម្រាប់ធ្វើការជាមួយ multithreading និង asynchrony ។ ភាគ១

ខ្ញុំកំពុងបោះពុម្ពអត្ថបទដើមនៅលើ Habr ដែលជាការបកប្រែដែលត្រូវបានបង្ហោះនៅក្នុងសាជីវកម្ម ការប្រកាសកំណត់ហេតុបណ្ដាញ.

តម្រូវការដើម្បីធ្វើអ្វីមួយដោយអសមកាល ដោយមិនរង់ចាំលទ្ធផលនៅទីនេះ និងឥឡូវនេះ ឬដើម្បីបែងចែកការងារធំ ៗ ក្នុងចំណោមអង្គភាពជាច្រើនដែលអនុវត្តវាមានមុនការមកដល់នៃកុំព្យូទ័រ។ ជាមួយនឹងវត្តមានរបស់ពួកគេ តម្រូវការនេះបានក្លាយជាជាក់ស្តែងណាស់។ ឥឡូវនេះនៅក្នុងឆ្នាំ 2019 ខ្ញុំកំពុងវាយអត្ថបទនេះនៅលើកុំព្យូទ័រយួរដៃដែលមានប្រព័ន្ធដំណើរការ 8-core Intel Core ដែលដំណើរការជាងមួយរយកំពុងដំណើរការស្របគ្នា និងសូម្បីតែខ្សែស្រឡាយជាច្រើនទៀត។ នៅក្បែរនោះមានទូរសព្ទរាងស្រួយបន្តិចដែលបានទិញកាលពីប៉ុន្មានឆ្នាំមុន វាមានប្រព័ន្ធដំណើរការ 8-core នៅលើយន្តហោះ។ ធនធានប្រធានបទគឺពោរពេញទៅដោយអត្ថបទ និងវីដេអូ ដែលអ្នកនិពន្ធរបស់ពួកគេកោតសរសើរចំពោះស្មាតហ្វូនកំពូលក្នុងឆ្នាំនេះ ដែលបំពាក់នូវប្រព័ន្ធដំណើរការ 16-core។ MS Azure ផ្តល់ម៉ាស៊ីននិម្មិតជាមួយនឹងខួរក្បាល 20 core និង RAM 128 TB ក្នុងតម្លៃតិចជាង $2 ក្នុងមួយម៉ោង។ ជាអកុសល វាមិនអាចទៅរួចទេក្នុងការទាញយកអតិបរមា និងប្រើប្រាស់ថាមពលនេះដោយមិនអាចគ្រប់គ្រងអន្តរកម្មនៃខ្សែស្រឡាយបានទេ។

ស័ព្ទ

ដំណើរការ - វត្ថុ OS, ចន្លោះអាសយដ្ឋានដាច់ស្រយាល, មានខ្សែស្រឡាយ។
ខ្សែស្រឡាយ - វត្ថុ OS ដែលជាអង្គភាពតូចបំផុតនៃការប្រតិបត្តិ ជាផ្នែកនៃដំណើរការ ខ្សែស្រឡាយចែករំលែកអង្គចងចាំ និងធនធានផ្សេងទៀតក្នុងចំណោមពួកគេនៅក្នុងដំណើរការមួយ។
ពហុមុខងារ - លក្ខណសម្បត្តិ OS សមត្ថភាពក្នុងការដំណើរការដំណើរការជាច្រើនក្នុងពេលដំណាលគ្នា។
ពហុស្នូល - លក្ខណៈសម្បត្តិរបស់ processor សមត្ថភាពប្រើប្រាស់ស្នូលជាច្រើនសម្រាប់ដំណើរការទិន្នន័យ
ដំណើរការច្រើន។ - ទ្រព្យសម្បត្តិរបស់កុំព្យូទ័រ សមត្ថភាពក្នុងការធ្វើការក្នុងពេលដំណាលគ្នាជាមួយ processors ជាច្រើនរូប
ពហុខ្សែ - ទ្រព្យសម្បត្តិនៃដំណើរការមួយ សមត្ថភាពក្នុងការចែកចាយដំណើរការទិន្នន័យក្នុងចំណោមខ្សែស្រឡាយជាច្រើន។
ភាពស្របគ្នា។ - អនុវត្តសកម្មភាពរាងកាយជាច្រើនក្នុងពេលដំណាលគ្នាក្នុងមួយឯកតានៃពេលវេលា
អសមកាល - ការប្រតិបត្តិនៃប្រតិបត្តិការដោយមិនរង់ចាំការបញ្ចប់នៃដំណើរការនេះ លទ្ធផលនៃការប្រតិបត្តិអាចត្រូវបានដំណើរការនៅពេលក្រោយ។

ការប្រៀបធៀប។

មិនមែននិយមន័យទាំងអស់សុទ្ធតែល្អទេ ហើយខ្លះត្រូវការការពន្យល់បន្ថែម ដូច្នេះខ្ញុំនឹងបន្ថែមពាក្យប្រៀបធៀបអំពីការចម្អិនអាហារអាហារពេលព្រឹកទៅពាក្យដែលណែនាំជាផ្លូវការ។ ការចម្អិនអាហារពេលព្រឹកនៅក្នុងពាក្យប្រៀបធៀបនេះគឺជាដំណើរការមួយ។

ពេលកំពុងរៀបចំអាហារពេលព្រឹក ខ្ញុំ (ស៊ីភីយូ) ខ្ញុំមកផ្ទះបាយ (កុំព្យូទ័រ។) ខ្ញុំមានដៃ 2 (ស្នូល) មានឧបករណ៍ជាច្រើននៅក្នុងផ្ទះបាយ (IO) : oven, kettle, toaster, ទូទឹកកក។ ខ្ញុំបើកហ្គាស ដាក់ខ្ទះចៀនលើវា ហើយចាក់ប្រេងចូលដោយមិនចាំវាឡើងកំដៅ (អសមកាល, មិនទប់ស្កាត់-IO-រង់ចាំ) ខ្ញុំយកស៊ុតចេញពីទូទឹកកក ហើយបំបែកវាចូលទៅក្នុងចាន បន្ទាប់មកវាយវាដោយដៃម្ខាង (ខ្សែស្រឡាយលេខ 1), និងទីពីរ (ខ្សែស្រឡាយលេខ 2) កាន់ចាន (ធនធានចែករំលែក) ។ ឥឡូវនេះខ្ញុំចង់បើកកំសៀវ ប៉ុន្តែខ្ញុំមិនមានដៃគ្រប់គ្រាន់ (ការអត់ឃ្លានខ្សែស្រឡាយ) ក្នុងអំឡុងពេលនេះខ្ទះចៀនឡើងកំដៅ (ដំណើរការលទ្ធផល) ដែលខ្ញុំចាក់អ្វីដែលខ្ញុំបាន whipped ។ ខ្ញុំឈោងទៅរកកំសៀវបើកហើយមើលទឹកដែលពុះក្នុងនោះ (ការទប់ស្កាត់-IO-រង់ចាំ) ទោះបីជាក្នុងអំឡុងពេលនេះគាត់អាចលាងចានដែលជាកន្លែងដែលគាត់បាន whipped omelet ។

ខ្ញុំចម្អិនអូមេឡែតដោយប្រើតែ២ដៃប៉ុណ្ណោះ ហើយខ្ញុំអត់មានទៀតទេ ប៉ុន្តែនៅពេលដំណាលគ្នានឹងការវាយពងអូមេឡេតនោះ ប្រតិបត្តិការ៣បានកើតឡើងក្នុងពេលតែមួយ៖ ការវាយពងអូមេឡែត កាន់ចានឡើងកំដៅខ្ទះ ។ ស៊ីភីយូគឺជាផ្នែកដែលលឿនបំផុតរបស់កុំព្យូទ័រ IO គឺជាអ្វីដែលភាគច្រើនតែងតែដំណើរការយឺត ដូច្នេះជារឿយៗដំណោះស្រាយដ៏មានប្រសិទ្ធភាពគឺការកាន់កាប់ស៊ីភីយូជាមួយនឹងអ្វីមួយ ខណៈពេលដែលទទួលទិន្នន័យពី IO ។

ការបន្តការប្រៀបធៀប៖

ប្រសិនបើនៅក្នុងដំណើរការនៃការរៀបចំ omelet មួយ ខ្ញុំក៏នឹងព្យាយាមផ្លាស់ប្តូរសម្លៀកបំពាក់ផងដែរ នេះនឹងក្លាយជាឧទាហរណ៍នៃកិច្ចការច្រើន។ ចំនុចសំខាន់មួយ៖ កុំព្យូទ័រមានភាពល្អប្រសើរជាងមនុស្ស។
ផ្ទះបាយដែលមានមេចុងភៅជាច្រើនឧទាហរណ៍នៅក្នុងភោជនីយដ្ឋាន - កុំព្យូទ័រពហុស្នូល។
ភោជនីយដ្ឋានជាច្រើននៅក្នុងទីធ្លាអាហារនៅក្នុងមជ្ឈមណ្ឌលផ្សារទំនើប - មជ្ឈមណ្ឌលទិន្នន័យ

ឧបករណ៍ .NET

.NET គឺល្អក្នុងការធ្វើការជាមួយ threads ដូចជាជាមួយរឿងជាច្រើនទៀត។ ជាមួយនឹងកំណែថ្មីនីមួយៗ វាណែនាំឧបករណ៍ថ្មីកាន់តែច្រើនឡើងសម្រាប់ធ្វើការជាមួយពួកគេ ស្រទាប់ថ្មីនៃភាពអរូបីលើខ្សែស្រឡាយ OS ។ នៅពេលធ្វើការជាមួយការសាងសង់អរូបី អ្នកអភិវឌ្ឍន៍ក្របខ័ណ្ឌប្រើប្រាស់វិធីសាស្រ្តដែលទុកឱកាស នៅពេលប្រើអរូបីកម្រិតខ្ពស់ ដើម្បីចុះទៅកម្រិតមួយ ឬច្រើនខាងក្រោម។ ភាគច្រើនវាមិនចាំបាច់ទេ តាមពិតវាបើកទ្វារបាញ់ខ្លួនឯងដោយកាំភ្លើងខ្លី ប៉ុន្តែពេលខ្លះក្នុងករណីកម្រ វាអាចជាវិធីតែមួយគត់ដើម្បីដោះស្រាយបញ្ហាដែលមិនត្រូវបានដោះស្រាយនៅកម្រិតបច្ចុប្បន្ននៃភាពអរូបី។ .

តាមរយៈឧបករណ៍ ខ្ញុំមានន័យថាទាំងចំណុចប្រទាក់កម្មវិធីកម្មវិធី (APIs) ដែលផ្តល់ដោយក្របខ័ណ្ឌ និងកញ្ចប់ភាគីទីបី ក៏ដូចជាដំណោះស្រាយកម្មវិធីទាំងមូលដែលសម្រួលដល់ការស្វែងរកបញ្ហាណាមួយដែលទាក់ទងនឹងកូដពហុខ្សែ។

ការចាប់ផ្តើមខ្សែស្រឡាយ

Thread class គឺជាថ្នាក់មូលដ្ឋានបំផុតនៅក្នុង .NET សម្រាប់ធ្វើការជាមួយ threads។ អ្នកសាងសង់ទទួលយកតំណាងម្នាក់ក្នុងចំណោមតំណាងពីរ៖

ThreadStart - គ្មានប៉ារ៉ាម៉ែត្រ
ParameterizedThreadStart - ជាមួយប៉ារ៉ាម៉ែត្រមួយនៃវត្ថុប្រភេទ។

ប្រតិភូនឹងត្រូវបានប្រតិបត្តិក្នុងខ្សែស្រឡាយដែលបានបង្កើតថ្មីបន្ទាប់ពីហៅវិធីសាស្ត្រចាប់ផ្តើម។ ប្រសិនបើប្រតិភូនៃប្រភេទ ParametrizedThreadStart ត្រូវបានបញ្ជូនទៅអ្នកបង្កើត នោះវត្ថុត្រូវតែត្រូវបានបញ្ជូនទៅវិធីសាស្ត្រចាប់ផ្តើម។ យន្តការនេះត្រូវការជាចាំបាច់ដើម្បីផ្ទេរព័ត៌មានក្នុងស្រុកណាមួយទៅកាន់ស្ទ្រីម។ វាគួរឱ្យកត់សម្គាល់ថាការបង្កើតខ្សែស្រឡាយគឺជាប្រតិបត្តិការថ្លៃហើយខ្សែស្រឡាយខ្លួនឯងគឺជាវត្ថុធ្ងន់យ៉ាងហោចណាស់ព្រោះវាបែងចែកអង្គចងចាំ 1MB នៅលើជង់ហើយត្រូវការអន្តរកម្មជាមួយ OS API ។

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

ថ្នាក់ ThreadPool តំណាងឱ្យគំនិតនៃអាងមួយ។ នៅក្នុង .NET, thread pool គឺជាផ្នែកមួយនៃវិស្វកម្ម ហើយអ្នកអភិវឌ្ឍន៍នៅ Microsoft បានខិតខំប្រឹងប្រែងយ៉ាងខ្លាំងក្នុងការធ្វើឱ្យប្រាកដថាវាដំណើរការបានល្អបំផុតនៅក្នុងសេណារីយ៉ូជាច្រើន។

គំនិតទូទៅ៖

ចាប់ពីពេលដែលកម្មវិធីចាប់ផ្តើម វាបង្កើតខ្សែស្រឡាយជាច្រើននៅក្នុងទុនបម្រុងក្នុងផ្ទៃខាងក្រោយ និងផ្តល់នូវសមត្ថភាពក្នុងការយកពួកវាទៅប្រើប្រាស់។ ប្រសិនបើខ្សែស្រឡាយត្រូវបានគេប្រើញឹកញាប់ និងក្នុងចំនួនច្រើន នោះក្រុមនឹងពង្រីកដើម្បីបំពេញតម្រូវការរបស់អ្នកហៅចូល។ នៅពេលដែលមិនមានខ្សែស្រលាយឥតគិតថ្លៃនៅក្នុងអាងនៅពេលត្រឹមត្រូវ វានឹងរង់ចាំសម្រាប់ខ្សែស្រឡាយណាមួយត្រឡប់មកវិញ ឬបង្កើតថ្មីមួយ។ វាដូចខាងក្រោមថាបណ្តុំខ្សែស្រឡាយគឺអស្ចារ្យសម្រាប់សកម្មភាពរយៈពេលខ្លីមួយចំនួន ហើយមិនសមស្របនឹងប្រតិបត្តិការដែលដំណើរការជាសេវាកម្មពេញមួយប្រតិបត្តិការទាំងមូលនៃកម្មវិធី។

ដើម្បីប្រើខ្សែស្រឡាយពីអាងនោះ មានវិធីសាស្ត្រ QueueUserWorkItem ដែលទទួលយកប្រតិភូនៃប្រភេទ WaitCallback ដែលមានហត្ថលេខាដូចគ្នានឹង ParametrizedThreadStart ហើយប៉ារ៉ាម៉ែត្រដែលបានបញ្ជូនទៅវាដំណើរការមុខងារដូចគ្នា។

ThreadPool.QueueUserWorkItem(...);

វិធីសាស្រ្តបណ្តុំខ្សែស្រឡាយដែលមិនសូវស្គាល់ RegisterWaitForSingleObject ត្រូវបានប្រើដើម្បីរៀបចំប្រតិបត្តិការ IO ដែលមិនទប់ស្កាត់។ ប្រតិភូដែលបានឆ្លងទៅវិធីសាស្ត្រនេះនឹងត្រូវបានហៅនៅពេលដែល WaitHandle ឆ្លងទៅវិធីសាស្ត្រ "ចេញផ្សាយ"។

ThreadPool.RegisterWaitForSingleObject(...)

.NET មានកម្មវិធីកំណត់ពេលវេលាខ្សែស្រឡាយ ហើយវាខុសពីកម្មវិធីកំណត់ម៉ោង WinForms/WPF ដែលឧបករណ៍ដោះស្រាយរបស់វានឹងត្រូវបានហៅនៅលើខ្សែស្រឡាយដែលយកចេញពីអាង។

System.Threading.Timer

វាក៏មានវិធីកម្រនិងអសកម្មផងដែរក្នុងការបញ្ជូនប្រតិភូសម្រាប់ការប្រតិបត្តិទៅកាន់ខ្សែស្រឡាយពីអាង - វិធីសាស្ត្រ BeginInvoke ។

DelegateInstance.BeginInvoke

ខ្ញុំចង់និយាយដោយសង្ខេបអំពីមុខងារដែលវិធីសាស្រ្តខាងលើជាច្រើនអាចត្រូវបានគេហៅថា - CreateThread ពី Kernel32.dll Win32 API ។ មានវិធីមួយ អរគុណចំពោះយន្តការនៃវិធីសាស្ត្រខាងក្រៅ ដើម្បីហៅមុខងារនេះ។ ខ្ញុំបានឃើញការហៅបែបនេះតែម្តងគត់ក្នុងឧទាហរណ៍ដ៏គួរឱ្យភ័យខ្លាចនៃកូដកេរដំណែល ហើយការលើកទឹកចិត្តរបស់អ្នកនិពន្ធដែលបានធ្វើវាយ៉ាងពិតប្រាកដនៅតែជាអាថ៌កំបាំងសម្រាប់ខ្ញុំ។

Kernel32.dll CreateThread

ការមើលនិងបំបាត់កំហុសខ្សែស្រឡាយ

Threads ដែលបង្កើតដោយអ្នក សមាសធាតុភាគីទីបីទាំងអស់ និងក្រុម .NET អាចត្រូវបានមើលនៅក្នុងបង្អួច Threads នៃ Visual Studio ។ វិនដូនេះនឹងបង្ហាញតែព័ត៌មានខ្សែស្រឡាយនៅពេលដែលកម្មវិធីស្ថិតនៅក្រោមការបំបាត់កំហុស និងនៅក្នុងរបៀបបំបែក។ នៅទីនេះអ្នកអាចមើលឈ្មោះជង់ និងអាទិភាពនៃខ្សែស្រឡាយនីមួយៗបានយ៉ាងងាយស្រួល ហើយប្តូរការកែកំហុសទៅជាខ្សែស្រឡាយជាក់លាក់មួយ។ ដោយប្រើលក្ខណសម្បត្តិអាទិភាពនៃថ្នាក់ Thread អ្នកអាចកំណត់អាទិភាពនៃខ្សែស្រឡាយ ដែល OC និង CLR នឹងយល់ថាជាការណែនាំនៅពេលបែងចែកពេលវេលាដំណើរការរវាងខ្សែស្រឡាយ។

បណ្ណាល័យប៉ារ៉ាឡែលកិច្ចការ

Task Parallel Library (TPL) ត្រូវបានណែនាំនៅក្នុង .NET 4.0។ ឥឡូវនេះវាគឺជាស្តង់ដារនិងជាឧបករណ៍សំខាន់សម្រាប់ធ្វើការជាមួយអសមកាល។ កូដណាមួយដែលប្រើវិធីសាស្រ្តចាស់ត្រូវបានចាត់ទុកថាជាកេរដំណែល។ ឯកតាមូលដ្ឋាននៃ TPL គឺជាថ្នាក់កិច្ចការពី System.Threading.Tasks namespace ។ កិច្ចការគឺជាការអរូបីលើខ្សែ។ ជាមួយនឹងកំណែថ្មីនៃភាសា C# យើងទទួលបានវិធីឆើតឆាយដើម្បីធ្វើការជាមួយ Tasks - async/await operators។ គោលគំនិតទាំងនេះបានធ្វើឱ្យវាអាចសរសេរកូដអសមកាល ហាក់ដូចជាសាមញ្ញ និងសមកាលកម្ម ដែលធ្វើឱ្យវាអាចធ្វើទៅបានសូម្បីតែសម្រាប់អ្នកដែលមានការយល់ដឹងតិចតួចអំពីការងារខាងក្នុងនៃខ្សែស្រឡាយដើម្បីសរសេរកម្មវិធីដែលប្រើពួកវា កម្មវិធីដែលមិនបង្កកនៅពេលប្រតិបត្តិការយូរ។ ការប្រើប្រាស់ async/await គឺជាប្រធានបទសម្រាប់អត្ថបទមួយ ឬសូម្បីតែអត្ថបទជាច្រើន ប៉ុន្តែខ្ញុំនឹងព្យាយាមស្វែងយល់ពីវានៅក្នុងប្រយោគមួយចំនួន៖

async គឺជាការកែប្រែនៃវិធីសាស្រ្តដែលត្រឡប់ភារកិច្ចឬមោឃៈ
ហើយរង់ចាំគឺជាប្រតិបត្តិកររង់ចាំភារកិច្ចដែលមិនរារាំង។

ជាថ្មីម្តងទៀត៖ ប្រតិបត្តិករដែលកំពុងរង់ចាំ ក្នុងករណីទូទៅ (មានករណីលើកលែង) នឹងចេញផ្សាយការប្រតិបត្តិបច្ចុប្បន្នបន្ថែមទៀត ហើយនៅពេលដែល Task បញ្ចប់ការប្រតិបត្តិរបស់វា និងខ្សែស្រឡាយ (តាមពិត វានឹងកាន់តែត្រឹមត្រូវក្នុងការនិយាយបរិបទ។ ប៉ុន្តែនៅពេលក្រោយទៀត) នឹងបន្តប្រតិបត្តិវិធីនេះបន្ថែមទៀត។ នៅខាងក្នុង .NET យន្តការនេះត្រូវបានអនុវត្តតាមរបៀបដូចគ្នាទៅនឹងទិន្នផលត្រឡប់មកវិញ នៅពេលដែលវិធីសាស្ត្រដែលបានសរសេរប្រែទៅជាថ្នាក់ទាំងមូល ដែលជាម៉ាស៊ីនរបស់រដ្ឋ ហើយអាចត្រូវបានអនុវត្តជាបំណែកដាច់ដោយឡែកអាស្រ័យលើរដ្ឋទាំងនេះ។ នរណាម្នាក់ដែលចាប់អារម្មណ៍អាចសរសេរកូដសាមញ្ញណាមួយដោយប្រើ asynс/await ចងក្រង និងមើលការជួបប្រជុំគ្នាដោយប្រើ JetBrains dotPeek ជាមួយនឹងកម្មវិធី Compiler Generated Code ដែលបានបើក។

សូមក្រឡេកមើលជម្រើសសម្រាប់ការបើកដំណើរការ និងប្រើប្រាស់ Task។ ក្នុងឧទាហរណ៍កូដខាងក្រោម យើងបង្កើតកិច្ចការថ្មីមួយដែលមិនមានប្រយោជន៍ (ខ្សែស្រឡាយ។ គេង (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
}

កិច្ចការត្រូវបានបង្កើតដោយមានជម្រើសជាច្រើន៖

LongRunning គឺជាតម្រុយមួយដែលថាកិច្ចការនឹងមិនត្រូវបានបញ្ចប់យ៉ាងឆាប់រហ័សនោះទេ ដែលមានន័យថាវាមានតម្លៃក្នុងការពិចារណាមិនយកខ្សែស្រឡាយចេញពីអាង ប៉ុន្តែការបង្កើតដាច់ដោយឡែកសម្រាប់កិច្ចការនេះ ដើម្បីកុំឱ្យប៉ះពាល់ដល់អ្នកដទៃ។
AttachedToParent - ភារកិច្ចអាចត្រូវបានរៀបចំតាមឋានានុក្រម។ ប្រសិនបើជម្រើសនេះត្រូវបានប្រើ នោះកិច្ចការអាចស្ថិតនៅក្នុងស្ថានភាពមួយដែលវាបានបញ្ចប់ ហើយកំពុងរង់ចាំការប្រតិបត្តិកូនរបស់វា។
PreferFairness - មានន័យថាវាជាការប្រសើរក្នុងការប្រតិបត្តិកិច្ចការដែលបានផ្ញើសម្រាប់ការប្រតិបត្តិមុនពេលដែលបានផ្ញើពេលក្រោយ។ ប៉ុន្តែនេះគ្រាន់តែជាការណែនាំប៉ុណ្ណោះ ហើយលទ្ធផលមិនត្រូវបានធានាទេ។

ប៉ារ៉ាម៉ែត្រទីពីរត្រូវបានបញ្ជូនទៅវិធីសាស្ត្រគឺ CancellationToken ។ ដើម្បីដោះស្រាយការលុបចោលប្រតិបត្តិការបានត្រឹមត្រូវបន្ទាប់ពីវាបានចាប់ផ្តើម កូដដែលកំពុងដំណើរការត្រូវតែបំពេញដោយការត្រួតពិនិត្យសម្រាប់ស្ថានភាព CancellationToken។ ប្រសិនបើមិនមានការត្រួតពិនិត្យទេ នោះវិធីសាស្ត្របោះបង់ដែលហៅថា CancellationTokenSource object នឹងអាចបញ្ឈប់ការប្រតិបត្តិនៃ Task មុនពេលវាចាប់ផ្តើមប៉ុណ្ណោះ។

ប៉ារ៉ាម៉ែត្រចុងក្រោយគឺជាវត្ថុកំណត់ពេលនៃប្រភេទ TaskScheduler ។ ថ្នាក់នេះ និងកូនចៅរបស់វាត្រូវបានរចនាឡើងដើម្បីគ្រប់គ្រងយុទ្ធសាស្ត្រសម្រាប់ចែកចាយកិច្ចការឆ្លងកាត់ខ្សែស្រឡាយ។ តាមលំនាំដើម កិច្ចការនឹងត្រូវបានប្រតិបត្តិលើខ្សែស្រឡាយចៃដន្យពីក្រុម។

ប្រតិបត្តិករដែលកំពុងរង់ចាំត្រូវបានអនុវត្តចំពោះកិច្ចការដែលបានបង្កើត ដែលមានន័យថាកូដដែលសរសេរបន្ទាប់ពីវា ប្រសិនបើមានមួយ នឹងត្រូវបានប្រតិបត្តិក្នុងបរិបទដូចគ្នា (ជារឿយៗវាមានន័យថានៅលើខ្សែអក្សរដូចគ្នា) ជាកូដមុនពេលរង់ចាំ។

វិធីសាស្ត្រត្រូវបានសម្គាល់ថា async void ដែលមានន័យថាវាអាចប្រើប្រតិបត្តិករដែលកំពុងរង់ចាំ ប៉ុន្តែលេខកូដហៅទូរសព្ទនឹងមិនអាចរង់ចាំការប្រតិបត្តិបានទេ។ ប្រសិនបើលក្ខណៈពិសេសបែបនេះគឺចាំបាច់ នោះវិធីសាស្ត្រត្រូវតែត្រឡប់ Task វិញ។ វិធីសាស្រ្តដែលត្រូវបានសម្គាល់ថា async ចាត់ទុកជាមោឃៈគឺជារឿងធម្មតាណាស់៖ ជាក្បួន ទាំងនេះគឺជាអ្នកដោះស្រាយព្រឹត្តិការណ៍ ឬវិធីសាស្រ្តផ្សេងទៀតដែលដំណើរការលើភ្លើង និងភ្លេចគោលការណ៍។ ប្រសិនបើអ្នកត្រូវការមិនត្រឹមតែផ្តល់ឱកាសឱ្យរង់ចាំរហូតដល់ចុងបញ្ចប់នៃការប្រតិបត្តិប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងផ្តល់លទ្ធផលមកវិញ នោះអ្នកត្រូវប្រើ 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/await គឺងាយស្រួលដោះស្រាយណាស់ - ពួកគេមានឥរិយាបទដូចគ្នាទៅនឹងកូដដែលធ្វើសមកាលកម្មដែរ។ ខណៈពេលដែលយើងអនុវត្តការរង់ចាំសមកាលកម្មទៅកិច្ចការមួយ ការលើកលែងដើមប្រែទៅជា AggregateException ពោលគឺ។ ដើម្បីដោះស្រាយករណីលើកលែង អ្នកនឹងត្រូវពិនិត្យមើលប្រភេទ InnerException ហើយសរសេរខ្សែសង្វាក់ដោយខ្លួនឯងនៅក្នុងប្លុកចាប់មួយ ឬប្រើការចាប់នៅពេលសាងសង់ ជំនួសឱ្យខ្សែសង្វាក់នៃប្លុកចាប់ដែលធ្លាប់ស្គាល់នៅក្នុងពិភព C# ។

ឧទាហរណ៍ទីបី និងចុងក្រោយក៏ត្រូវបានសម្គាល់ថាមិនល្អសម្រាប់ហេតុផលដូចគ្នា និងមានបញ្ហាដូចគ្នាទាំងអស់។

វិធីសាស្ត្រ WhenAny និង WhenAll គឺងាយស្រួលបំផុតសម្រាប់ការរង់ចាំក្រុម Tasks ពួកវារុំក្រុម Tasks ទៅជាមួយ ដែលនឹងបាញ់នៅពេលដែល Task ពីក្រុមត្រូវបានកេះជាលើកដំបូង ឬនៅពេលដែលពួកគេទាំងអស់បានបញ្ចប់ការប្រតិបត្តិរបស់ពួកគេ។

ការបញ្ឈប់ខ្សែស្រឡាយ

សម្រាប់ហេតុផលផ្សេងៗ វាអាចចាំបាច់ដើម្បីបញ្ឈប់លំហូរបន្ទាប់ពីវាបានចាប់ផ្តើម។ មានវិធីជាច្រើនដើម្បីធ្វើរឿងនេះ។ ថ្នាក់ Thread មានវិធីសាស្រ្តពីរដែលមានឈ្មោះត្រឹមត្រូវ៖ បោះបង់ и ផ្អាក. ទីមួយគឺមិនត្រូវបានណែនាំអោយប្រើទេព្រោះ បន្ទាប់ពីហៅវានៅពេលចៃដន្យ កំឡុងពេលដំណើរការនៃការណែនាំណាមួយ ការលើកលែងនឹងត្រូវបានបោះចោល ThreadAbortedException. អ្នកមិនរំពឹងថាការលើកលែងបែបនេះត្រូវបានបោះចោលនៅពេលបង្កើនអថេរចំនួនគត់ទេមែនទេ? ហើយនៅពេលប្រើវិធីនេះ នេះគឺជាស្ថានភាពជាក់ស្តែងណាស់។ ប្រសិនបើអ្នកត្រូវការការពារ CLR ពីការបង្កើតករណីលើកលែងបែបនេះនៅក្នុងផ្នែកជាក់លាក់នៃកូដ អ្នកអាចរុំវានៅក្នុងការហៅទូរសព្ទ។ Thread.BeginCriticalRegion, Thread.EndCriticalRegion. លេខកូដណាមួយដែលសរសេរនៅក្នុងប្លុកចុងក្រោយគឺត្រូវបានរុំដោយការហៅបែបនេះ។ សម្រាប់ហេតុផលនេះ នៅក្នុងជម្រៅនៃកូដក្របខ័ណ្ឌ អ្នកអាចរកឃើញប្លុកជាមួយនឹងការព្យាយាមទទេ ប៉ុន្តែចុងក្រោយមិនមែនជាទទេនោះទេ។ Microsoft បំបាក់ទឹកចិត្តវិធីសាស្ត្រនេះយ៉ាងខ្លាំង ដែលពួកគេមិនបានបញ្ចូលវាទៅក្នុង .net core។

វិធីសាស្ត្រ Interrupt មានប្រសិទ្ធភាពជាង។ វាអាចរំខានខ្សែស្រឡាយដោយមានករណីលើកលែងមួយ។ ThreadInterruptedException មានតែក្នុងអំឡុងពេលទាំងនោះនៅពេលដែលខ្សែស្រឡាយស្ថិតនៅក្នុងស្ថានភាពរង់ចាំ។ វាចូលក្នុងស្ថានភាពនេះ ពេលកំពុងព្យួរ ខណៈពេលរង់ចាំ WaitHandle ចាក់សោ ឬបន្ទាប់ពីហៅទូរសព្ទទៅ Thread.Sleep។

ជម្រើសទាំងពីរដែលបានពិពណ៌នាខាងលើគឺមិនល្អដោយសារតែមិនអាចទាយទុកជាមុនបាន។ ដំណោះស្រាយគឺប្រើរចនាសម្ព័ន្ធ CancellationToken និងថ្នាក់ ប្រភព CancellationToken. ចំនុចគឺនេះ៖ ឧទាហរណ៍នៃថ្នាក់ CancellationTokenSource ត្រូវបានបង្កើតឡើង ហើយមានតែអ្នកដែលជាម្ចាស់វាប៉ុណ្ណោះដែលអាចបញ្ឈប់ប្រតិបត្តិការដោយហៅវិធីសាស្ត្រ បោះបង់. មានតែ CancellationToken ប៉ុណ្ណោះដែលត្រូវបានបញ្ជូនទៅប្រតិបត្តិការដោយខ្លួនឯង។ ម្ចាស់ CancellationToken មិនអាចលុបចោលប្រតិបត្តិការដោយខ្លួនឯងបានទេ ប៉ុន្តែគ្រាន់តែអាចពិនិត្យមើលថាតើប្រតិបត្តិការនេះត្រូវបានលុបចោលឬអត់។ មានទ្រព្យសម្បត្តិប៊ូលីនសម្រាប់ការនេះ។ ត្រូវបានស្នើសុំការលុបចោល និងវិធីសាស្រ្ត ស្នើសុំបោះបង់. ក្រោយមកទៀតនឹងលើកករណីលើកលែងមួយ។ TaskCelledException ប្រសិនបើវិធីសាស្ត្របោះបង់ត្រូវបានហៅនៅលើឧទាហរណ៍ CancellationToken កំពុងត្រូវបានញែក។ ហើយនេះគឺជាវិធីសាស្រ្តដែលខ្ញុំណែនាំអោយប្រើ។ នេះគឺជាការកែលម្អលើជម្រើសពីមុន ដោយទទួលបានការគ្រប់គ្រងពេញលេញ នៅចំណុចណាដែលប្រតិបត្តិការលើកលែងអាចត្រូវបានលុបចោល។

ជម្រើសដ៏ឃោរឃៅបំផុតសម្រាប់ការបញ្ឈប់ខ្សែស្រឡាយគឺការហៅមុខងារ Win32 API TerminateThread ។ ឥរិយាបថរបស់ CLR បន្ទាប់ពីហៅមុខងារនេះប្រហែលជាមិនអាចទាយទុកជាមុនបាន។ នៅលើ MSDN ខាងក្រោមនេះត្រូវបានសរសេរអំពីមុខងារនេះ៖ "TerminateThread គឺជាមុខងារដ៏គ្រោះថ្នាក់ដែលគួរតែត្រូវបានប្រើតែនៅក្នុងករណីធ្ងន់ធ្ងរបំផុត។ “

ការបំប្លែង API ចាស់ទៅ Task Based ដោយប្រើវិធីសាស្ត្រ FromAsync

ប្រសិនបើអ្នកមានសំណាងគ្រប់គ្រាន់ក្នុងការធ្វើការលើគម្រោងដែលបានចាប់ផ្តើមបន្ទាប់ពី Tasks ត្រូវបានណែនាំ និងឈប់បង្កភាពភ័យរន្ធត់ស្ងាត់ៗសម្រាប់អ្នកអភិវឌ្ឍន៍ភាគច្រើន នោះអ្នកនឹងមិនចាំបាច់ដោះស្រាយជាមួយ APIs ចាស់ៗច្រើនទេ ទាំងភាគីទីបី និងក្រុមរបស់អ្នក បានធ្វើទារុណកម្មកាលពីអតីតកាល។ សំណាងហើយ ដែលក្រុមការងារ .NET Framework បានមើលថែយើង ទោះបីជាគោលដៅគឺដើម្បីថែរក្សាខ្លួនយើងក៏ដោយ។ ត្រូវហើយតាមដែលអាចធ្វើបាន .NET មានឧបករណ៍មួយចំនួនសម្រាប់បំប្លែងកូដដោយមិនឈឺចាប់ ដែលសរសេរក្នុងកម្មវិធីអសមកាលចាស់ ខិតទៅជិតលេខថ្មី។ មួយក្នុងចំណោមពួកគេគឺជាវិធីសាស្ត្រ FromAsync នៃ TaskFactory ។ ក្នុងឧទាហរណ៍កូដខាងក្រោម ខ្ញុំរុំវិធីសាស្ត្រ async ចាស់នៃថ្នាក់ WebRequest ក្នុង Task ដោយប្រើវិធីសាស្ត្រនេះ។

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

នេះគ្រាន់តែជាឧទាហរណ៍មួយប៉ុណ្ណោះ ហើយអ្នកទំនងជាមិនត្រូវធ្វើបែបនេះជាមួយនឹងប្រភេទដែលភ្ជាប់មកជាមួយនោះទេ ប៉ុន្តែគម្រោងចាស់ណាមួយកំពុងដំណើរការយ៉ាងសាមញ្ញជាមួយនឹងវិធីសាស្រ្ត BeginDoSomething ដែលត្រឡប់វិធីសាស្ត្រ IAsyncResult និង EndDoSomething ដែលទទួលវា។

បំប្លែង API ចាស់ទៅជា Task Based ដោយប្រើថ្នាក់ TaskCompletionSource

ឧបករណ៍សំខាន់មួយទៀតដែលត្រូវពិចារណាគឺថ្នាក់ ប្រភព TaskCompletion. នៅក្នុងលក្ខខណ្ឌនៃមុខងារ គោលបំណង និងគោលការណ៍នៃប្រតិបត្តិការ វាអាចនឹកឃើញខ្លះៗពីវិធីសាស្ត្រ RegisterWaitForSingleObject នៃថ្នាក់ ThreadPool ដែលខ្ញុំបានសរសេរអំពីខាងលើ។ ដោយប្រើថ្នាក់នេះ អ្នកអាចរុំ APIs អសមកាលចាស់បានយ៉ាងងាយស្រួល និងងាយស្រួលនៅក្នុង Tasks ។

អ្នកនឹងនិយាយថាខ្ញុំបាននិយាយរួចហើយអំពីវិធីសាស្ត្រ FromAsync នៃថ្នាក់ TaskFactory ដែលមានបំណងសម្រាប់គោលបំណងទាំងនេះ។ នៅទីនេះ យើងនឹងត្រូវចងចាំពីប្រវត្តិទាំងមូលនៃការអភិវឌ្ឍន៍គំរូអសមកាលនៅក្នុង .net ដែល Microsoft បានផ្តល់ជូនក្នុងរយៈពេល 15 ឆ្នាំកន្លងមកនេះ៖ មុនពេល Task-Based Asynchronous Pattern (TAP) មាន Asynchronous Programming Pattern (APP) ដែល គឺអំពីវិធីសាស្រ្ត ចាប់ផ្តើមធ្វើអ្វីមួយត្រឡប់មកវិញ លទ្ធផល IAsync និងវិធីសាស្រ្ត បញ្ចប់DoSomething ដែលទទួលយកវា និងសម្រាប់កេរ្តិ៍ដំណែលនៃឆ្នាំទាំងនេះ វិធីសាស្ត្រ FromAsync គឺគ្រាន់តែល្អឥតខ្ចោះ ប៉ុន្តែយូរៗទៅវាត្រូវបានជំនួសដោយ Event Based Asynchronous Pattern (EAP) ដែលសន្មត់ថាព្រឹត្តិការណ៍មួយនឹងត្រូវបានលើកឡើងនៅពេលដែលប្រតិបត្តិការអសមកាលបានបញ្ចប់។

TaskCompletionSource គឺល្អឥតខ្ចោះសម្រាប់ការរុំ Tasks និង APIs ចាស់ដែលបានបង្កើតឡើងនៅជុំវិញគំរូព្រឹត្តិការណ៍។ ខ្លឹមសារនៃការងាររបស់វាមានដូចខាងក្រោម៖ វត្ថុនៃថ្នាក់នេះមានទ្រព្យសម្បត្តិសាធារណៈនៃប្រភេទ Task ស្ថានភាពដែលអាចត្រូវបានគ្រប់គ្រងតាមរយៈ SetResult, SetException ជាដើម។ វិធីសាស្ត្រនៃថ្នាក់ TaskCompletionSource ។ នៅកន្លែងដែលប្រតិបត្តិកររង់ចាំត្រូវបានអនុវត្តចំពោះកិច្ចការនេះ វានឹងត្រូវបានប្រតិបត្តិ ឬបរាជ័យដោយមានករណីលើកលែងមួយអាស្រ័យលើវិធីសាស្ត្រដែលបានអនុវត្តចំពោះ TaskCompletionSource ។ ប្រសិនបើវានៅតែមិនច្បាស់ សូមក្រឡេកមើលឧទាហរណ៍កូដនេះ ដែល EAP API ចាស់មួយចំនួនត្រូវបានរុំក្នុង Task ដោយប្រើ TaskCompletionSource៖ នៅពេលដែលព្រឹត្តិការណ៍នេះកើតឡើង កិច្ចការនឹងត្រូវបានផ្ទេរទៅស្ថានភាពដែលបានបញ្ចប់ ហើយវិធីសាស្ត្រដែលបានអនុវត្តប្រតិបត្តិករដែលកំពុងរង់ចាំ។ កិច្ចការនេះនឹងបន្តការប្រតិបត្តិរបស់វាឡើងវិញ បន្ទាប់ពីបានទទួលវត្ថុ លទ្ធផល.

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 Tips & Tricks

ការរុំ APIs ចាស់គឺមិនមែនទាំងអស់ដែលអាចធ្វើបានដោយប្រើ TaskCompletionSource នោះទេ។ ការប្រើថ្នាក់នេះបើកលទ្ធភាពគួរឱ្យចាប់អារម្មណ៍ក្នុងការរចនា APIs ផ្សេងៗនៅលើ Tasks ដែលមិនកាន់កាប់ខ្សែស្រឡាយ។ ហើយស្ទ្រីមដូចដែលយើងចងចាំគឺជាធនធានថ្លៃហើយចំនួនរបស់ពួកគេត្រូវបានកំណត់ (ជាចម្បងដោយចំនួន RAM) ។ ការកំណត់នេះអាចសម្រេចបានយ៉ាងងាយស្រួលដោយបង្កើតជាឧទាហរណ៍ កម្មវិធីគេហទំព័រដែលផ្ទុកដោយតក្កវិជ្ជាអាជីវកម្មស្មុគស្មាញ។ ចូរយើងពិចារណាពីលទ្ធភាពដែលខ្ញុំកំពុងនិយាយនៅពេលអនុវត្តល្បិចដូចជា Long-Polling។

សរុបមក ខ្លឹមសារនៃល្បិចនេះគឺ៖ អ្នកត្រូវទទួលព័ត៌មានពី API អំពីព្រឹត្តិការណ៍មួយចំនួនដែលកើតឡើងនៅខាងរបស់វា ខណៈដែល API សម្រាប់ហេតុផលមួយចំនួនមិនអាចរាយការណ៍ព្រឹត្តិការណ៍នេះបានទេ ប៉ុន្តែអាចត្រឡប់ស្ថានភាពវិញ។ ឧទាហរណ៍នៃទាំងនេះគឺជា APIs ទាំងអស់ដែលត្រូវបានបង្កើតឡើងនៅលើកំពូលនៃ HTTP មុនពេលសម័យនៃ WebSocket ឬនៅពេលដែលវាមិនអាចទៅរួចសម្រាប់ហេតុផលមួយចំនួនដើម្បីប្រើបច្ចេកវិទ្យានេះ។ អតិថិជនអាចសួរម៉ាស៊ីនមេ HTTP ។ ម៉ាស៊ីនមេ HTTP ខ្លួនឯងមិនអាចចាប់ផ្តើមទំនាក់ទំនងជាមួយអតិថិជនបានទេ។ ដំណោះស្រាយដ៏សាមញ្ញមួយគឺការស្ទង់មតិលើម៉ាស៊ីនមេដោយប្រើកម្មវិធីកំណត់ម៉ោង ប៉ុន្តែវាបង្កើតបន្ទុកបន្ថែមនៅលើម៉ាស៊ីនមេ និងការពន្យាពេលបន្ថែមលើមធ្យម TimerInterval / 2។ ដើម្បីដោះស្រាយបញ្ហានេះ ល្បិចមួយដែលហៅថា Long Polling ត្រូវបានបង្កើតឡើង ដែលពាក់ព័ន្ធនឹងការពន្យារពេលការឆ្លើយតបពី ម៉ាស៊ីនមេរហូតដល់អស់ពេលផុតកំណត់ ឬព្រឹត្តិការណ៍នឹងកើតឡើង។ ប្រសិនបើព្រឹត្តិការណ៍បានកើតឡើង នោះវាត្រូវបានដំណើរការ បើមិនដូច្នេះទេ សំណើត្រូវបានផ្ញើម្តងទៀត។

while(!eventOccures && !timeoutExceeded)  {

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

ប៉ុន្តែដំណោះស្រាយបែបនេះនឹងបង្ហាញពីភាពអាក្រក់ភ្លាមៗនៅពេលដែលចំនួនអតិថិជនដែលរង់ចាំព្រឹត្តិការណ៍កើនឡើងព្រោះ... អតិថិជនបែបនេះនីមួយៗកាន់កាប់ខ្សែស្រឡាយទាំងមូលរង់ចាំព្រឹត្តិការណ៍មួយ។ បាទ/ចាស ហើយយើងទទួលបានការពន្យារពេល 1ms បន្ថែមនៅពេលដែលព្រឹត្តិការណ៍ត្រូវបានបង្កឡើង ភាគច្រើនជាញឹកញាប់វាមិនសំខាន់ទេ ប៉ុន្តែហេតុអ្វីបានជាធ្វើឱ្យកម្មវិធីកាន់តែអាក្រក់ជាងនេះទៅទៀត? ប្រសិនបើយើងដក Thread.Sleep(1) ចេញ នោះដោយឥតប្រយោជន៍ យើងនឹងផ្ទុកស្នូលដំណើរការមួយ 100% ទំនេរ ដោយបង្វិលក្នុងវដ្តដែលគ្មានប្រយោជន៍។ ដោយប្រើ TaskCompletionSource អ្នកអាចបង្កើតកូដនេះឡើងវិញបានយ៉ាងងាយស្រួល និងដោះស្រាយបញ្ហាទាំងអស់ដែលបានកំណត់ខាងលើ៖

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

កូដនេះមិនទាន់ផលិតរួចរាល់ទេ ប៉ុន្តែគ្រាន់តែជាការបង្ហាញប៉ុណ្ណោះ។ ដើម្បីប្រើវានៅក្នុងករណីជាក់ស្តែង អ្នកក៏ត្រូវការយ៉ាងហោចណាស់ផងដែរ ដើម្បីដោះស្រាយស្ថានភាពនៅពេលដែលសារមកដល់នៅពេលដែលគ្មាននរណាម្នាក់រំពឹងថាវា៖ ក្នុងករណីនេះ វិធីសាស្ត្រ AsseptMessageAsync គួរតែត្រឡប់កិច្ចការដែលបានបញ្ចប់រួចហើយ។ ប្រសិនបើនេះជាករណីទូទៅបំផុតនោះ អ្នកអាចគិតអំពីការប្រើប្រាស់ ValueTask ។

នៅពេលដែលយើងទទួលបានសំណើសម្រាប់សារមួយ យើងបង្កើត និងដាក់ TaskCompletionSource នៅក្នុងវចនានុក្រម ហើយបន្ទាប់មករង់ចាំអ្វីដែលកើតឡើងជាមុនសិន៖ ចន្លោះពេលដែលបានបញ្ជាក់ផុតកំណត់ ឬសារត្រូវបានទទួល។

ValueTask៖ ហេតុអ្វី និងរបៀប

ប្រតិបត្តិករ async/await ដូចជា yield return operator បង្កើតម៉ាស៊ីន state ពី method ហើយនេះគឺជាការបង្កើត object ថ្មី ដែលស្ទើរតែមិនសំខាន់ ប៉ុន្តែក្នុងករណីកម្រ វាអាចបង្កើតបញ្ហាបាន។ ករណីនេះអាចជាវិធីសាស្រ្តមួយដែលត្រូវបានគេហៅថាជាញឹកញាប់ យើងកំពុងនិយាយអំពីការហៅទូរសព្ទរាប់ម៉ឺន និងរាប់រយរាប់ពាន់ក្នុងមួយវិនាទី។ ប្រសិនបើវិធីសាស្ត្របែបនេះត្រូវបានសរសេរតាមរបៀបដែលក្នុងករណីភាគច្រើនវាត្រឡប់លទ្ធផលដោយរំលងវិធីសាស្ត្រដែលរង់ចាំទាំងអស់នោះ .NET ផ្តល់ឧបករណ៍ដើម្បីបង្កើនប្រសិទ្ធភាពនេះ - រចនាសម្ព័ន្ធ ValueTask ។ ដើម្បីធ្វើឱ្យវាច្បាស់សូមមើលឧទាហរណ៍នៃការប្រើប្រាស់របស់វា: មានឃ្លាំងសម្ងាត់ដែលយើងចូលទៅជាញឹកញាប់ណាស់។ មានតម្លៃខ្លះនៅក្នុងវា ហើយបន្ទាប់មកយើងគ្រាន់តែបញ្ជូនពួកវាមកវិញ បើមិនដូច្នោះទេ យើងទៅកាន់ IO យឺតខ្លះដើម្បីយកពួកវា។ ខ្ញុំចង់ធ្វើអសមកាលចុងក្រោយ ដែលមានន័យថាវិធីសាស្ត្រទាំងមូលប្រែទៅជាអសមកាល។ ដូចនេះ វិធីសាស្ត្រជាក់ស្តែងក្នុងការសរសេរមានដូចខាងក្រោម៖

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

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

ដោយសារតែបំណងប្រាថ្នាដើម្បីបង្កើនប្រសិទ្ធភាពបន្តិចបន្តួច និងការភ័យខ្លាចបន្តិចនៃអ្វីដែល Roslyn នឹងបង្កើតនៅពេលចងក្រងកូដនេះ អ្នកអាចសរសេរឧទាហរណ៍នេះឡើងវិញដូចខាងក្រោម៖

public Task<string> GetById(int id) {

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

ជាការពិត ដំណោះស្រាយដ៏ល្អប្រសើរក្នុងករណីនេះគឺដើម្បីបង្កើនប្រសិទ្ធភាពផ្លូវក្តៅ ពោលគឺការទទួលបានតម្លៃពីវចនានុក្រមដោយមិនមានការបែងចែកដែលមិនចាំបាច់ និងផ្ទុកនៅលើ GC ខណៈពេលដែលក្នុងករណីដ៏កម្រនោះ នៅពេលដែលយើងនៅតែត្រូវការចូលទៅកាន់ IO សម្រាប់ទិន្នន័យ។ អ្វីគ្រប់យ៉ាងនឹងនៅតែបូក / ដកតាមរបៀបចាស់៖

public ValueTask<string> GetById(int id) {

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

សូមពិនិត្យមើលឱ្យកាន់តែដិតដល់នូវបំណែកនៃកូដនេះ៖ ប្រសិនបើមានតម្លៃនៅក្នុងឃ្លាំងសម្ងាត់ យើងបង្កើតរចនាសម្ព័ន្ធមួយ បើមិនដូច្នេះទេ កិច្ចការពិតប្រាកដនឹងត្រូវបានរុំដោយអត្ថន័យមួយ។ លេខកូដហៅទូរសព្ទមិនខ្វល់ថាផ្លូវណាដែលកូដនេះត្រូវបានប្រតិបត្តិក្នុង៖ ValueTask តាមទស្សនៈវាក្យសម្ព័ន្ធ C# នឹងប្រព្រឹត្តដូចគ្នានឹងកិច្ចការធម្មតាក្នុងករណីនេះដែរ។

TaskSchedulers៖ គ្រប់គ្រងយុទ្ធសាស្ត្រចាប់ផ្តើមការងារ

API បន្ទាប់ដែលខ្ញុំចង់ពិចារណាគឺថ្នាក់ កម្មវិធីកំណត់ពេលភារកិច្ច និងនិស្សន្ទវត្ថុរបស់វា។ ខ្ញុំបានរៀបរាប់ខាងលើរួចហើយថា TPL មានសមត្ថភាពក្នុងការគ្រប់គ្រងយុទ្ធសាស្រ្តសម្រាប់ការចែកចាយភារកិច្ចឆ្លងកាត់ខ្សែស្រលាយ។ យុទ្ធសាស្ត្របែបនេះត្រូវបានកំណត់នៅក្នុងកូនចៅនៃថ្នាក់ TaskScheduler ។ ស្ទើរតែគ្រប់យុទ្ធសាស្ត្រដែលអ្នកប្រហែលជាត្រូវការអាចរកបាននៅក្នុងបណ្ណាល័យ។ ParallelExtensionsExtrasបង្កើតឡើងដោយ Microsoft ប៉ុន្តែមិនមែនជាផ្នែកនៃ .NET ទេ ប៉ុន្តែត្រូវបានផ្គត់ផ្គង់ជាកញ្ចប់ Nuget ។ សូមក្រឡេកមើលពួកគេខ្លះដោយសង្ខេប៖

CurrentThreadTaskScheduler - ប្រតិបត្តិ Tasks នៅលើខ្សែស្រឡាយបច្ចុប្បន្ន
LimitedConcurrencyLevelTaskScheduler - កំណត់ចំនួនកិច្ចការដែលត្រូវប្រតិបត្តិក្នុងពេលដំណាលគ្នាដោយប៉ារ៉ាម៉ែត្រ N ដែលត្រូវបានទទួលយកនៅក្នុង constructor
បានបញ្ជាទិញ TaskScheduler — ត្រូវបានកំណត់ថាជា LimitedConcurrencyLevelTaskScheduler(1) ដូច្នេះកិច្ចការនឹងត្រូវបានប្រតិបត្តិតាមលំដាប់លំដោយ។
កម្មវិធីកំណត់ម៉ោងការងារ - ឧបករណ៍ប្រើប្រាស់ លួចការងារ វិធីសាស្រ្តក្នុងការចែកចាយភារកិច្ច។ សំខាន់វាគឺជា ThreadPool ដាច់ដោយឡែក។ ដោះស្រាយបញ្ហាដែលនៅក្នុង .NET ThreadPool គឺជាថ្នាក់ឋិតិវន្ត មួយសម្រាប់កម្មវិធីទាំងអស់ ដែលមានន័យថាការផ្ទុកលើសទម្ងន់ ឬការប្រើប្រាស់មិនត្រឹមត្រូវនៅក្នុងផ្នែកមួយនៃកម្មវិធីអាចនាំឱ្យមានផលប៉ះពាល់នៅក្នុងកម្មវិធីផ្សេងទៀត។ ជាងនេះទៅទៀត វាជាការលំបាកខ្លាំងណាស់ក្នុងការយល់ដឹងពីមូលហេតុនៃពិការភាពបែបនេះ។ នោះ។ ប្រហែលជាមានតម្រូវការប្រើប្រាស់ WorkStealingTaskSchedulers ដាច់ដោយឡែកនៅក្នុងផ្នែកនៃកម្មវិធី ដែលការប្រើប្រាស់ ThreadPool អាចមានភាពឆេវឆាវ និងមិនអាចទាយទុកជាមុនបាន។
QueuedTaskScheduler - អនុញ្ញាតឱ្យអ្នកអនុវត្តភារកិច្ចដោយយោងទៅតាមច្បាប់ជួរអាទិភាព
ThreadPerTaskScheduler - បង្កើតខ្សែស្រឡាយដាច់ដោយឡែកសម្រាប់កិច្ចការនីមួយៗដែលត្រូវបានប្រតិបត្តិលើវា។ អាចមានប្រយោជន៍សម្រាប់កិច្ចការដែលចំណាយពេលយូរដែលមិនអាចទាយទុកជាមុនបានដើម្បីបញ្ចប់។

មានព័ត៌មានលម្អិតល្អ។ អត្ថបទ អំពី TaskSchedulers នៅលើប្លុករបស់ Microsoft ។

សម្រាប់ការកែកំហុសដ៏ងាយស្រួលនៃអ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹង Tasks, Visual Studio មានបង្អួច Tasks ។ នៅក្នុងបង្អួចនេះ អ្នកអាចមើលឃើញស្ថានភាពបច្ចុប្បន្ននៃកិច្ចការ ហើយលោតទៅបន្ទាត់នៃកូដដែលកំពុងដំណើរការ។

PLinq និងថ្នាក់ប៉ារ៉ាឡែល

បន្ថែមពីលើ Tasks និងអ្វីគ្រប់យ៉ាងដែលនិយាយអំពីពួកវា មានឧបករណ៍គួរឱ្យចាប់អារម្មណ៍ពីរទៀតនៅក្នុង .NET៖ PLinq (Linq2Parallel) និងថ្នាក់ប៉ារ៉ាឡែល។ ទីមួយសន្យាថានឹងដំណើរការស្របគ្នានៃប្រតិបត្តិការ Linq ទាំងអស់នៅលើខ្សែស្រឡាយច្រើន។ ចំនួនខ្សែស្រឡាយអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើវិធីបន្ថែម WithDegreeOfParallelism ។ ជាអកុសល ភាគច្រើនជាញឹកញាប់ PLinq នៅក្នុងរបៀបលំនាំដើមរបស់វាមិនមានព័ត៌មានគ្រប់គ្រាន់អំពីផ្នែកខាងក្នុងនៃប្រភពទិន្នន័យរបស់អ្នកដើម្បីផ្តល់នូវការបង្កើនល្បឿនគួរឱ្យកត់សម្គាល់នោះទេ ម្យ៉ាងវិញទៀតតម្លៃនៃការព្យាយាមគឺទាបណាស់៖ អ្នកគ្រាន់តែត្រូវការហៅវិធីសាស្ត្រ AsParallel ជាមុនសិន។ ខ្សែសង្វាក់នៃវិធីសាស្រ្ត Linq និងដំណើរការការធ្វើតេស្តការអនុវត្ត។ លើសពីនេះទៅទៀត វាអាចបញ្ជូនព័ត៌មានបន្ថែមទៅ PLinq អំពីលក្ខណៈនៃប្រភពទិន្នន័យរបស់អ្នកដោយប្រើយន្តការភាគថាស។ អ្នកអាចអានបន្ថែម នៅទីនេះ и នៅទីនេះ.

ថ្នាក់ឋិតិវន្តប៉ារ៉ាឡែលផ្ដល់នូវវិធីសាស្រ្តសម្រាប់ការធ្វើឡើងវិញតាមរយៈការប្រមូល Foreach ស្របគ្នា ប្រតិបត្តិរង្វិលជុំ និងប្រតិបត្តិប្រតិភូជាច្រើននៅក្នុងការហៅប៉ារ៉ាឡែល។ ការប្រតិបត្តិនៃខ្សែស្រឡាយបច្ចុប្បន្ននឹងត្រូវបញ្ឈប់រហូតដល់ការគណនាត្រូវបានបញ្ចប់។ ចំនួនខ្សែស្រឡាយអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយឆ្លងកាត់ ParallelOptions ជាអាគុយម៉ង់ចុងក្រោយ។ អ្នកក៏អាចបញ្ជាក់ TaskScheduler និង CancellationToken ដោយប្រើជម្រើស។

ការរកឃើញ

នៅពេលខ្ញុំចាប់ផ្តើមសរសេរអត្ថបទនេះដោយផ្អែកលើឯកសារនៃរបាយការណ៍របស់ខ្ញុំ និងព័ត៌មានដែលខ្ញុំប្រមូលបានក្នុងអំឡុងពេលការងាររបស់ខ្ញុំបន្ទាប់ពីវា ខ្ញុំមិនរំពឹងថានឹងមានវាច្រើននោះទេ។ ឥឡូវនេះ នៅពេលដែលកម្មវិធីនិពន្ធអត្ថបទដែលខ្ញុំកំពុងវាយអត្ថបទនេះ ស្តីបន្ទោសប្រាប់ខ្ញុំថា ទំព័រទី 15 បានទៅ ខ្ញុំនឹងសង្ខេបលទ្ធផលបណ្តោះអាសន្ន។ ល្បិចផ្សេងទៀត APIs ឧបករណ៍មើលឃើញ និងរណ្តៅនឹងត្រូវបានគ្របដណ្តប់នៅក្នុងអត្ថបទបន្ទាប់។

សេចក្តីសន្និដ្ឋាន:

អ្នកត្រូវដឹងពីឧបករណ៍សម្រាប់ធ្វើការជាមួយខ្សែស្រឡាយ អសមកាល និងប៉ារ៉ាឡែល ដើម្បីប្រើប្រាស់ធនធាននៃកុំព្យូទ័រទំនើប។
.NET មានឧបករណ៍ផ្សេងគ្នាជាច្រើនសម្រាប់គោលបំណងទាំងនេះ
មិនមែនពួកវាទាំងអស់បានបង្ហាញខ្លួនក្នុងពេលតែមួយនោះទេ ដូច្នេះជារឿយៗអ្នកអាចស្វែងរកកេរ្តិ៍ដំណែលបាន ប៉ុន្តែមានវិធីដើម្បីបំប្លែង APIs ចាស់ៗដោយមិនចាំបាច់ប្រឹងប្រែងច្រើន។
ការធ្វើការជាមួយខ្សែស្រឡាយក្នុង .NET ត្រូវបានតំណាងដោយថ្នាក់ Thread និង ThreadPool
វិធីសាស្ត្រ Thread.Abort, Thread.Interrupt, និង Win32 API TerminateThread គឺមានគ្រោះថ្នាក់ ហើយមិនត្រូវបានណែនាំសម្រាប់ប្រើប្រាស់ទេ។ ជំនួសមកវិញ វាជាការប្រសើរក្នុងការប្រើយន្តការ CancellationToken
លំហូរគឺជាធនធានដ៏មានតម្លៃ ហើយការផ្គត់ផ្គង់របស់វាមានកម្រិត។ ស្ថានភាពដែលខ្សែស្រឡាយរវល់រង់ចាំព្រឹត្តិការណ៍គួរតែត្រូវបានជៀសវាង។ សម្រាប់ការនេះ វាងាយស្រួលប្រើថ្នាក់ TaskCompletionSource
ឧបករណ៍ .NET ដែលមានអនុភាព និងទំនើបបំផុតសម្រាប់ធ្វើការជាមួយភាពស្របគ្នា និងអសមកាល គឺជាកិច្ចការ។
ប្រតិបត្តិករ c# async/await អនុវត្តគំនិតនៃការរង់ចាំមិនរារាំង
អ្នកអាចគ្រប់គ្រងការចែកចាយកិច្ចការនៅទូទាំងខ្សែស្រឡាយដោយប្រើថ្នាក់ដែលបានមកពី TaskScheduler
រចនាសម្ព័ន្ធ ValueTask អាចមានប្រយោជន៍ក្នុងការបង្កើនប្រសិទ្ធភាព hot-paths និង memory-traffic
វិនដូ Tasks and Threads របស់ Visual Studio ផ្តល់នូវព័ត៌មានជាច្រើនដែលមានប្រយោជន៍សម្រាប់ការកែកំហុសកូដពហុខ្សែ ឬអសមកាល
PLinq គឺជាឧបករណ៍ដ៏ល្អមួយ ប៉ុន្តែវាប្រហែលជាមិនមានព័ត៌មានគ្រប់គ្រាន់អំពីប្រភពទិន្នន័យរបស់អ្នកទេ ប៉ុន្តែវាអាចត្រូវបានជួសជុលដោយប្រើយន្តការបែងចែក
នៅមានជាបន្តទៀត…

ប្រភព: www.habr.com

.NET៖ ឧបករណ៍សម្រាប់ធ្វើការជាមួយ multithreading និង asynchrony ។ ផ្នែកទី 1