.NET: ເຄື່ອງມືສໍາລັບການເຮັດວຽກກັບ multithreading ແລະ asynchrony. ພາກທີ 1

ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ພິມ​ເຜີຍ​ແຜ່​ບົດ​ຄວາມ​ຕົ້ນ​ສະ​ບັບ​ກ່ຽວ​ກັບ Habr, ການ​ແປ​ພາ​ສາ​ທີ່​ໄດ້​ຮັບ​ການ​ຈັດ​ພີມ​ມາ​ໃນ​ບໍ​ລິ​ສັດ blog post.

ຄວາມຕ້ອງການທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງ asynchronously, ໂດຍບໍ່ມີການລໍຖ້າຜົນໄດ້ຮັບຢູ່ທີ່ນີ້ແລະໃນປັດຈຸບັນ, ຫຼືການແບ່ງວຽກຂະຫນາດໃຫຍ່ລະຫວ່າງຫຼາຍຫນ່ວຍງານປະຕິບັດມັນ, ມີຢູ່ກ່ອນການມາຂອງຄອມພິວເຕີ. ດ້ວຍການມາເຖິງຂອງພວກເຂົາ, ຄວາມຕ້ອງການນີ້ໄດ້ກາຍເປັນທີ່ຊັດເຈນຫຼາຍ. ໃນປັດຈຸບັນ, ໃນປີ 2019, ຂ້ອຍກໍາລັງພິມບົດຄວາມນີ້ຢູ່ໃນຄອມພິວເຕີໂນດບຸກທີ່ມີໂປເຊດເຊີ Intel Core 8-core, ເຊິ່ງມີຫຼາຍກວ່າຫນຶ່ງຮ້ອຍຂະບວນການເຮັດວຽກຂະຫນານ, ແລະແມ້ກະທັ້ງຫຼາຍກະທູ້. ຢູ່ໃກ້ໆ, ມີໂທລະສັບທີ່ຂີ້ຮ້າຍເລັກນ້ອຍ, ຊື້ສອງສາມປີກ່ອນ, ມັນມີໂປເຊດເຊີ 8-core ຢູ່ເທິງເຮືອ. ຊັບພະຍາກອນຫົວຂໍ້ແມ່ນເຕັມໄປດ້ວຍບົດຄວາມແລະວິດີໂອທີ່ຜູ້ຂຽນຂອງພວກເຂົາຊົມເຊີຍໂທລະສັບສະຫຼາດ flagship ໃນປີນີ້ທີ່ມີໂປເຊດເຊີ 16-core. MS Azure ສະໜອງເຄື່ອງສະເໝືອນກັບໂປເຊດເຊີ 20 core ແລະ RAM 128 TB ໃນລາຄາຕໍ່າກວ່າ $2/ຊົ່ວໂມງ. ແຕ່ຫນ້າເສຍດາຍ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສະກັດສູງສຸດແລະ harness ພະລັງງານນີ້ໂດຍບໍ່ສາມາດຈັດການການໂຕ້ຕອບຂອງກະທູ້.

Terminology

ຂະບວນການ - ວັດຖຸ OS, ພື້ນທີ່ທີ່ຢູ່ໂດດດ່ຽວ, ມີກະທູ້.
ກະທູ້ - ວັດຖຸ OS, ຫນ່ວຍງານທີ່ນ້ອຍທີ່ສຸດຂອງການປະຕິບັດ, ສ່ວນຫນຶ່ງຂອງຂະບວນການ, ກະທູ້ແບ່ງປັນຫນ່ວຍຄວາມຈໍາແລະຊັບພະຍາກອນອື່ນໆລະຫວ່າງເຂົາເຈົ້າພາຍໃນຂະບວນການ.
Multitasking - ຄຸນສົມບັດ OS, ຄວາມສາມາດໃນການດໍາເນີນການຫຼາຍຂະບວນການພ້ອມໆກັນ
ຫຼາຍຫຼັກ - ຄຸນສົມບັດຂອງໂປເຊດເຊີ, ຄວາມສາມາດໃນການນໍາໃຊ້ຫຼາຍແກນສໍາລັບການປະມວນຜົນຂໍ້ມູນ
Multiprocessing - ຄຸນສົມບັດຂອງຄອມພິວເຕີ, ຄວາມສາມາດໃນການເຮັດວຽກພ້ອມໆກັນກັບໂປເຊດເຊີຫຼາຍຕົວ
Multithreading — ຊັບ​ສິນ​ຂອງ​ຂະ​ບວນ​ການ​, ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ແຈກ​ຢາຍ​ການ​ປຸງ​ແຕ່ງ​ຂໍ້​ມູນ​ໃນ​ບັນ​ດາ​ຫຼາຍ​ກະ​ທູ້​.
ຂະໜານ - ປະຕິບັດຫຼາຍໆຄັ້ງທາງຮ່າງກາຍພ້ອມໆກັນຕໍ່ຫົວໜ່ວຍເວລາ
Asynchrony — ການ​ປະ​ຕິ​ບັດ​ການ​ດໍາ​ເນີນ​ງານ​ໂດຍ​ບໍ່​ມີ​ການ​ລໍ​ຖ້າ​ສໍາ​ລັບ​ການ​ສໍາ​ເລັດ​ຂອງ​ການ​ປຸງ​ແຕ່ງ​ນີ້​ຜົນ​ຂອງ​ການ​ປະ​ຕິ​ບັດ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ພາຍ​ຫຼັງ​.

ການປຽບທຽບ

ບໍ່ແມ່ນຄໍານິຍາມທັງຫມົດແມ່ນດີແລະບາງອັນຕ້ອງການຄໍາອະທິບາຍເພີ່ມເຕີມ, ດັ່ງນັ້ນຂ້າພະເຈົ້າຈະເພີ່ມຄໍາອຸປະມາກ່ຽວກັບການແຕ່ງກິນອາຫານເຊົ້າເປັນຄໍາສັບທີ່ແນະນໍາຢ່າງເປັນທາງການ. ການແຕ່ງກິນອາຫານເຊົ້າໃນຄໍາປຽບທຽບນີ້ແມ່ນຂະບວນການ.

ໃນຂະນະທີ່ກະກຽມອາຫານເຊົ້າໃນຕອນເຊົ້າຂ້ອຍ (CPU) ຂ້ອຍມາເຮືອນຄົວ (ຄອມພິວເຕີ). ຂ້ອຍມີ 2 ມື (Cores). ມີອຸປະກອນຈໍານວນຫນຶ່ງຢູ່ໃນເຮືອນຄົວ (IO): ເຕົາອົບ, ເຕົາອົບ, ເຕົາອົບ, ຕູ້ເຢັນ. ຂ້ອຍເປີດອາຍແກັສ, ເອົາເຕົາຂົ້ວໃສ່ມັນແລະຖອກນ້ໍາມັນໃສ່ມັນໂດຍບໍ່ຕ້ອງລໍຖ້າໃຫ້ມັນຮ້ອນ (asynchronously, Non-blocking-IO-Wait), ເອົາໄຂ່ອອກຈາກຕູ້ເຢັນແລະແຕກມັນເຂົ້າໄປໃນແຜ່ນ, ຫຼັງຈາກນັ້ນຕີມັນດ້ວຍມືຫນຶ່ງ (ກະທູ້ #1), ແລະທີສອງ (ກະທູ້ #2) ຖືແຜ່ນ (ຊັບພະຍາກອນທີ່ແບ່ງປັນ). ດຽວນີ້ຂ້ອຍຢາກເປີດກະຕຸກ, ແຕ່ຂ້ອຍບໍ່ມີມືພໍ (ຄວາມອຶດຫິວກະທູ້) ໃນ​ລະ​ຫວ່າງ​ເວ​ລາ​ນີ້​, ແຊ່ frying ໄດ້ heats ເຖິງ (ການ​ປຸງ​ແຕ່ງ​ຜົນ​ໄດ້​ຮັບ​) ເຂົ້າ​ໄປ​ໃນ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ງາມ​ສິ່ງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້ whipped​. ຂ້າ​ພະ​ເຈົ້າ​ເອື້ອມ​ເຖິງ​ກະ​ຕຸກ​ແລະ​ເປີດ​ມັນ​ແລະ stupidly ເບິ່ງ​ນ​້​ໍ​າ​ຕົ້ມ​ໃນ​ມັນ (ການຂັດຂວາງ-IO-ລໍຖ້າ), ເຖິງແມ່ນວ່າໃນລະຫວ່າງເວລານີ້ລາວສາມາດລ້າງຈານບ່ອນທີ່ລາວຕີ omelet ໄດ້.

ຂ້າ​ພະ​ເຈົ້າ​ປຸງ​ແຕ່ງ omelette ໂດຍ​ໃຊ້​ພຽງ​ແຕ່ 2 ມື​, ແລະ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ມີ​ຫຼາຍ​, ແຕ່​ໃນ​ຂະ​ນະ​ດຽວ​ກັນ​, ໃນ​ປັດ​ຈຸ​ບັນ​ຂອງ​ການ whipping omelette ໄດ້​, ການ​ດໍາ​ເນີນ​ການ 3 ຄັ້ງ​ໄດ້​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​: whipping omelette​, ຖື​ຈານ​, ແຊ່​ຮ້ອນ​. . CPU ແມ່ນສ່ວນທີ່ໄວທີ່ສຸດຂອງຄອມພິວເຕີ, IO ແມ່ນສິ່ງທີ່ສ່ວນຫຼາຍມັກຈະຊ້າລົງ, ດັ່ງນັ້ນເລື້ອຍໆການແກ້ໄຂທີ່ມີປະສິດທິພາບຄືການຄອບຄອງ CPU ກັບບາງສິ່ງບາງຢ່າງໃນຂະນະທີ່ໄດ້ຮັບຂໍ້ມູນຈາກ IO.

ສືບຕໍ່ການປຽບທຽບ:

• ຖ້າຢູ່ໃນຂະບວນການກະກຽມ omelet, ຂ້ອຍກໍ່ພະຍາຍາມປ່ຽນເຄື່ອງນຸ່ງ, ນີ້ຈະເປັນຕົວຢ່າງຂອງການເຮັດຫຼາຍວຽກ. ເປັນ nuance ທີ່​ສໍາ​ຄັນ​: ຄອມ​ພິວ​ເຕີ​ແມ່ນ​ດີກ​ວ່າ​ຫຼາຍ​ໃນ​ນີ້​ກ​່​ວາ​ຄົນ​.
• ເຮືອນຄົວທີ່ມີພໍ່ຄົວຫຼາຍຄົນ, ຕົວຢ່າງໃນຮ້ານອາຫານ - ຄອມພິວເຕີຫຼາຍຫຼັກ.
• ຮ້ານອາຫານຈໍານວນຫຼາຍຢູ່ໃນສູນອາຫານໃນສູນການຄ້າ - data center

.NET ເຄື່ອງມື

.NET ແມ່ນດີໃນການເຮັດວຽກກັບກະທູ້, ເຊັ່ນດຽວກັນກັບສິ່ງອື່ນໆຈໍານວນຫຼາຍ. ດ້ວຍແຕ່ລະຮຸ່ນໃຫມ່, ມັນແນະນໍາເຄື່ອງມືໃຫມ່ໆຫຼາຍຂື້ນສໍາລັບການເຮັດວຽກກັບພວກມັນ, ຊັ້ນໃຫມ່ຂອງ abstraction ໃນໄລຍະກະທູ້ OS. ໃນເວລາທີ່ເຮັດວຽກກັບການກໍ່ສ້າງຂອງ abstractions, ນັກພັດທະນາກອບການນໍາໃຊ້ວິທີການທີ່ປ່ອຍໃຫ້ໂອກາດ, ໃນເວລາທີ່ນໍາໃຊ້ abstraction ລະດັບສູງ, ລົງຫນຶ່ງຫຼືຫຼາຍລະດັບຂ້າງລຸ່ມນີ້. ສ່ວນຫຼາຍມັກ, ນີ້ບໍ່ແມ່ນຄວາມຈໍາເປັນ, ໃນຄວາມເປັນຈິງມັນເປີດປະຕູເພື່ອຍິງຕົວເອງດ້ວຍປືນຍິງ, ແຕ່ບາງຄັ້ງ, ໃນກໍລະນີທີ່ຫາຍາກ, ມັນອາດຈະເປັນວິທີດຽວທີ່ຈະແກ້ໄຂບັນຫາທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂໃນລະດັບປະຈຸບັນ. .

ໂດຍເຄື່ອງມື, ຂ້າພະເຈົ້າຫມາຍຄວາມວ່າທັງສອງການໂຕ້ຕອບການຂຽນໂປລແກລມຂອງແອັບພລິເຄຊັນ (APIs) ທີ່ສະຫນອງໃຫ້ໂດຍກອບແລະແພກເກດພາກສ່ວນທີສາມ, ເຊັ່ນດຽວກັນກັບການແກ້ໄຂຊອບແວທັງຫມົດທີ່ເຮັດໃຫ້ການຄົ້ນຫາງ່າຍສໍາລັບບັນຫາໃດໆທີ່ກ່ຽວຂ້ອງກັບລະຫັດຫຼາຍກະທູ້.

ກຳລັງເລີ່ມຫົວຂໍ້

ຫ້ອງຮຽນ Thread ເປັນຫ້ອງຮຽນພື້ນຖານທີ່ສຸດໃນ .NET ສໍາລັບການເຮັດວຽກກັບກະທູ້. ຜູ້ກໍ່ສ້າງຍອມຮັບຫນຶ່ງໃນສອງຕົວແທນ:

• ThreadStart — ບໍ່​ມີ​ຕົວ​ກໍາ​ນົດ​ການ​
• ParameterizedThreadStart - ມີຫນຶ່ງພາລາມິເຕີຂອງວັດຖຸປະເພດ.

ຕົວແທນຈະຖືກປະຕິບັດໃນກະທູ້ທີ່ສ້າງຂຶ້ນໃຫມ່ຫຼັງຈາກໂທຫາວິທີການເລີ່ມຕົ້ນ ຖ້າຕົວແທນຂອງປະເພດ ParametrizedThreadStart ຖືກສົ່ງກັບຜູ້ກໍ່ສ້າງ, ຫຼັງຈາກນັ້ນ, ວັດຖຸຕ້ອງຖືກສົ່ງກັບວິທີການເລີ່ມຕົ້ນ. ກົນໄກນີ້ແມ່ນຈໍາເປັນເພື່ອໂອນຂໍ້ມູນທ້ອງຖິ່ນໃດໆໄປສູ່ກະແສ. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າການສ້າງ thread ແມ່ນການດໍາເນີນງານລາຄາແພງ, ແລະ thread ຕົວຂອງມັນເອງເປັນວັດຖຸທີ່ຫນັກແຫນ້ນ, ຢ່າງຫນ້ອຍເນື່ອງຈາກວ່າມັນຈັດສັນຫນ່ວຍຄວາມຈໍາ 1MB ໃນ stack ແລະຮຽກຮ້ອງໃຫ້ມີການໂຕ້ຕອບກັບ 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. ມີວິທີການ, ຂໍຂອບໃຈກັບກົນໄກຂອງວິທີການ extern, ໂທຫາຫນ້າທີ່ນີ້. ຂ້າພະເຈົ້າໄດ້ເຫັນການໂທດັ່ງກ່າວພຽງແຕ່ຄັ້ງດຽວໃນຕົວຢ່າງທີ່ຂີ້ຮ້າຍຂອງລະຫັດມໍລະດົກ, ແລະແຮງຈູງໃຈຂອງຜູ້ຂຽນທີ່ເຮັດແບບນີ້ຍັງຄົງເປັນຄວາມລຶກລັບສໍາລັບຂ້ອຍ.

Kernel32.dll CreateThread

ການເບິ່ງແລະການແກ້ບັນຫາກະທູ້

ກະທູ້ທີ່ສ້າງໂດຍທ່ານ, ອົງປະກອບພາກສ່ວນທີສາມທັງຫມົດ, ແລະ .NET pool ສາມາດເບິ່ງໄດ້ຢູ່ໃນປ່ອງຢ້ຽມ Threads ຂອງ Visual Studio. ປ່ອງ​ຢ້ຽມ​ນີ້​ຈະ​ສະ​ແດງ​ຂໍ້​ມູນ​ຂ່າວ​ສານ​ພຽງ​ແຕ່​ໃນ​ເວ​ລາ​ທີ່​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແມ່ນ​ຢູ່​ໃນ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ແລະ​ໃນ​ຮູບ​ແບບ Break . ທີ່ນີ້ທ່ານສາມາດເບິ່ງຊື່ stack ແລະບູລິມະສິດຂອງແຕ່ລະ thread ໄດ້ສະດວກ, ແລະສະຫຼັບ debugging ກັບຫົວຂໍ້ສະເພາະໃດຫນຶ່ງ. ການນໍາໃຊ້ຄຸນສົມບັດບູລິມະສິດຂອງຊັ້ນ Thread, ທ່ານສາມາດກໍານົດຄວາມສໍາຄັນຂອງ thread, ເຊິ່ງ OC ແລະ CLR ຈະຮັບຮູ້ວ່າເປັນຄໍາແນະນໍາໃນເວລາທີ່ແບ່ງເວລາຂອງໂປເຊດເຊີລະຫວ່າງກະທູ້.

Task Parallel Library

Task Parallel Library (TPL) ຖືກນໍາສະເຫນີໃນ .NET 4.0. ໃນປັດຈຸບັນມັນເປັນມາດຕະຖານແລະເຄື່ອງມືຕົ້ນຕໍສໍາລັບການເຮັດວຽກກັບ asynchrony. ລະຫັດໃດໆທີ່ນໍາໃຊ້ວິທີການເກົ່າແກ່ແມ່ນຖືວ່າເປັນມໍລະດົກ. ຫົວໜ່ວຍພື້ນຖານຂອງ TPL ແມ່ນຫ້ອງຮຽນ Task ຈາກ System.Threading.Tasks namespace. ວຽກງານແມ່ນເປັນສິ່ງຫຍໍ້ທໍ້ໃນໄລຍະກະທູ້. ດ້ວຍພາສາ C# ສະບັບໃໝ່, ພວກເຮົາມີວິທີທີ່ສະຫງ່າງາມໃນການເຮັດວຽກກັບ Tasks - async/await operators . ແນວຄວາມຄິດເຫຼົ່ານີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນລະຫັດ asynchronous ຄືກັບວ່າມັນງ່າຍດາຍແລະ synchronous, ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ເຖິງແມ່ນວ່າສໍາລັບຄົນທີ່ມີຄວາມເຂົ້າໃຈຫນ້ອຍກ່ຽວກັບການເຮັດວຽກພາຍໃນຂອງກະທູ້ທີ່ຈະຂຽນຄໍາຮ້ອງສະຫມັກທີ່ນໍາໃຊ້ພວກມັນ, ຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ແຊ່ແຂໍງໃນເວລາປະຕິບັດການຍາວ. ການນໍາໃຊ້ async / await ແມ່ນຫົວຂໍ້ຫນຶ່ງຫຼືແມ້ກະທັ້ງຫຼາຍບົດຄວາມ, ແຕ່ຂ້ອຍຈະພະຍາຍາມເອົາຄວາມສໍາຄັນຂອງມັນຢູ່ໃນສອງສາມປະໂຫຍກ:

• async ແມ່ນຕົວແກ້ໄຂວິທີການສົ່ງຄືນ Task ຫຼື void
• ແລະລໍຖ້າແມ່ນຕົວປະຕິບັດການລໍຖ້າ Task ທີ່ບໍ່ປິດກັ້ນ.

ອີກເທື່ອ ໜຶ່ງ: ຜູ້ປະຕິບັດການລໍຖ້າ, ໃນກໍລະນີທົ່ວໄປ (ມີຂໍ້ຍົກເວັ້ນ), ຈະປ່ອຍກະທູ້ປະຈຸບັນຂອງການປະຕິບັດຕື່ມອີກ, ແລະເມື່ອ Task ສໍາເລັດການປະຕິບັດ, ແລະກະທູ້ (ໃນຄວາມເປັນຈິງ, ມັນຈະຖືກຕ້ອງກວ່າທີ່ຈະເວົ້າສະພາບການ. , ແຕ່ເພີ່ມເຕີມກ່ຽວກັບວ່າຕໍ່ມາ) ຈະສືບຕໍ່ປະຕິບັດວິທີການຕື່ມອີກ. ພາຍໃນ .NET, ກົນໄກນີ້ຖືກປະຕິບັດໃນລັກສະນະດຽວກັນກັບຜົນຕອບແທນຂອງຜົນຜະລິດ, ເມື່ອວິທີການຂຽນປ່ຽນເປັນຊັ້ນທັງຫມົດ, ເຊິ່ງເປັນເຄື່ອງຈັກຂອງລັດແລະສາມາດປະຕິບັດໄດ້ໃນຕ່ອນແຍກຕ່າງຫາກຂຶ້ນຢູ່ກັບລັດເຫຼົ່ານີ້. ໃຜກໍ່ຕາມທີ່ສົນໃຈສາມາດຂຽນລະຫັດງ່າຍໆໂດຍໃຊ້ asynс / ລໍຖ້າ, ລວບລວມແລະເບິ່ງການປະກອບໂດຍໃຊ້ JetBrains dotPeek ກັບ Compiler Generated Code ເປີດໃຊ້.

ໃຫ້ເບິ່ງທາງເລືອກສໍາລັບການເປີດຕົວແລະການນໍາໃຊ້ Task. ໃນຕົວຢ່າງລະຫັດຂ້າງລຸ່ມນີ້, ພວກເຮົາສ້າງວຽກງານໃຫມ່ທີ່ບໍ່ມີປະໂຫຍດ (ກະທູ້.ນອນ (10000)), ແຕ່ໃນຊີວິດຈິງນີ້ຄວນຈະເປັນການເຮັດວຽກທີ່ຊັບຊ້ອນ CPU ຫຼາຍ.

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
}

A Task ຖືກ​ສ້າງ​ຂຶ້ນ​ໂດຍ​ມີ​ຈໍາ​ນວນ​ຂອງ​ທາງ​ເລືອກ​:

• LongRunning ແມ່ນຄໍາແນະນໍາວ່າວຽກງານຈະບໍ່ສໍາເລັດຢ່າງໄວວາ, ຊຶ່ງຫມາຍຄວາມວ່າມັນອາດຈະຄຸ້ມຄ່າທີ່ຈະບໍ່ເອົາກະທູ້ອອກຈາກສະນຸກເກີ, ແຕ່ສ້າງແຍກຕ່າງຫາກສໍາລັບວຽກງານນີ້ເພື່ອບໍ່ເປັນອັນຕະລາຍຕໍ່ຄົນອື່ນ.
• AttachedToParent - ວຽກງານສາມາດຈັດລຽງຕາມລຳດັບ. ຖ້າທາງເລືອກນີ້ຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນ Task ອາດຈະຢູ່ໃນສະຖານະທີ່ມັນເອງໄດ້ສໍາເລັດແລະລໍຖ້າການປະຕິບັດຂອງລູກຂອງມັນ.
• PreferFairness - ຫມາຍຄວາມວ່າມັນຈະດີກວ່າທີ່ຈະປະຕິບັດຫນ້າວຽກທີ່ສົ່ງສໍາລັບການປະຕິບັດກ່ອນຫນ້ານັ້ນກ່ອນທີ່ຈະສົ່ງຕໍ່ມາ. ແຕ່ນີ້ແມ່ນພຽງແຕ່ຄໍາແນະນໍາແລະຜົນໄດ້ຮັບບໍ່ໄດ້ຮັບປະກັນ.

ພາລາມິເຕີທີສອງທີ່ຜ່ານໄປຫາວິທີການແມ່ນ CancellationToken. ເພື່ອຈັດການການຍົກເລີກການດຳເນີນການຢ່າງຖືກຕ້ອງຫຼັງຈາກທີ່ມັນເລີ່ມຕົ້ນແລ້ວ, ລະຫັດທີ່ຖືກປະຕິບັດຈະຕ້ອງເຕັມໄປດ້ວຍການກວດສອບສະຖານະ CancellationToken. ຖ້າບໍ່ມີການກວດສອບ, ຫຼັງຈາກນັ້ນ, ວິທີການຍົກເລີກທີ່ເອີ້ນຢູ່ໃນວັດຖຸ CancellationTokenSource ຈະສາມາດຢຸດເຊົາການດໍາເນີນການຂອງ Task ພຽງແຕ່ກ່ອນທີ່ມັນຈະເລີ່ມຕົ້ນ.

ຕົວກໍານົດການສຸດທ້າຍແມ່ນວັດຖຸກໍານົດເວລາຂອງປະເພດຂອງ TaskScheduler. ຊັ້ນຮຽນນີ້ແລະລູກຫລານຂອງມັນຖືກອອກແບບເພື່ອຄວບຄຸມຍຸດທະສາດການແຈກຢາຍ Tasks ໃນທົ່ວຫົວຂໍ້ໂດຍຄ່າເລີ່ມຕົ້ນ, 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
}

ໃນຕົວຢ່າງທໍາອິດ, ພວກເຮົາລໍຖ້າ Task ສໍາເລັດໂດຍບໍ່ມີການສະກັດກະທູ້ການໂທ;

ໃນທາງເລືອກທີສອງ, ພວກເຮົາຕັນກະທູ້ການໂທຈົນກ່ວາຜົນໄດ້ຮັບຂອງວິທີການໄດ້ຖືກຄິດໄລ່. ນີ້ແມ່ນບໍ່ດີບໍ່ພຽງແຕ່ຍ້ອນວ່າພວກເຮົາໄດ້ຄອບຄອງກະທູ້, ຊັບພະຍາກອນອັນມີຄ່າຂອງໂປລແກລມ, ມີຄວາມງຽບໆງ່າຍດາຍ, ແຕ່ຍັງຍ້ອນວ່າຖ້າລະຫັດຂອງວິທີການທີ່ພວກເຮົາເອີ້ນວ່າມີລໍຖ້າຢູ່, ແລະສະພາບການ synchronization ຮຽກຮ້ອງໃຫ້ກັບຄືນໄປຫາຫົວຂໍ້ໂທຫາພາຍຫຼັງ. ລໍຖ້າ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະໄດ້ຮັບການ deadlock : ກະທູ້ການໂທລໍຖ້າໃນຂະນະທີ່ຜົນໄດ້ຮັບຂອງວິທີການ asynchronous ໄດ້ຖືກຄິດໄລ່, ວິທີການ asynchronous ພະຍາຍາມໃນ vain ສືບຕໍ່ການປະຕິບັດຂອງຕົນໃນກະທູ້ການໂທ.

ຂໍ້ເສຍອີກອັນຫນຶ່ງຂອງວິທີການນີ້ແມ່ນການຈັດການຄວາມຜິດພາດທີ່ສັບສົນ. ຄວາມຈິງແມ່ນວ່າຄວາມຜິດພາດໃນລະຫັດ asynchronous ເມື່ອໃຊ້ async/await ແມ່ນງ່າຍຕໍ່ການຈັດການ - ພວກມັນປະຕິບັດຄືກັນກັບວ່າລະຫັດຖືກ synchronous. ໃນຂະນະທີ່ຖ້າພວກເຮົານໍາໃຊ້ການລໍຖ້າ synchronous exorcism ກັບ Task, ຂໍ້ຍົກເວັ້ນຕົ້ນສະບັບປ່ຽນເປັນ AggregateException, i.e. ເພື່ອຈັດການກັບຂໍ້ຍົກເວັ້ນ, ທ່ານຈະຕ້ອງກວດເບິ່ງປະເພດ InnerException ແລະຂຽນສາຍຕ່ອງໂສ້ຖ້າຕົວທ່ານເອງຢູ່ໃນຕັນຈັບຫນຶ່ງຫຼືໃຊ້ການຈັບໃນເວລາທີ່ການກໍ່ສ້າງ, ແທນທີ່ຈະເປັນຕ່ອງໂສ້ຂອງຕັນຈັບທີ່ຄຸ້ນເຄີຍໃນໂລກ C #.

ຕົວຢ່າງທີສາມແລະສຸດທ້າຍແມ່ນຍັງຖືກຫມາຍວ່າບໍ່ດີສໍາລັບເຫດຜົນດຽວກັນແລະປະກອບດ້ວຍບັນຫາດຽວກັນທັງຫມົດ.

ວິທີການ WhenAny ແລະ WhenAll ແມ່ນສະດວກທີ່ສຸດສໍາລັບການລໍຖ້າກຸ່ມ Tasks;

ການຢຸດເຊົາກະທູ້

ສໍາລັບເຫດຜົນຕ່າງໆ, ມັນອາດຈະຈໍາເປັນຕ້ອງຢຸດເຊົາການໄຫຼຫຼັງຈາກທີ່ມັນໄດ້ເລີ່ມຕົ້ນ. ມີຫຼາຍວິທີທີ່ຈະເຮັດແນວນີ້. ຫ້ອງຮຽນກະທູ້ມີສອງວິທີການທີ່ມີຊື່ທີ່ເຫມາະສົມ: ເອົາລູກອອກ и ຂັດຂວາງ. ອັນທໍາອິດແມ່ນບໍ່ແນະນໍາໃຫ້ໃຊ້, ເພາະວ່າ ຫຼັງຈາກໂທຫາມັນໃນເວລາສຸ່ມໃດກໍ່ຕາມ, ໃນລະຫວ່າງການປຸງແຕ່ງຄໍາແນະນໍາໃດໆ, ຂໍ້ຍົກເວັ້ນຈະຖືກຖິ້ມ ກະທູ້AbortedException. ທ່ານບໍ່ຄາດຫວັງວ່າການຍົກເວັ້ນດັ່ງກ່າວຈະຖືກຖິ້ມໃນເວລາທີ່ເພີ່ມຕົວແປ integer, ແມ່ນບໍ? ແລະໃນເວລາທີ່ໃຊ້ວິທີການນີ້, ນີ້ແມ່ນສະຖານະການທີ່ແທ້ຈິງຫຼາຍ. ຖ້າທ່ານຕ້ອງການປ້ອງກັນ CLR ຈາກການສ້າງຂໍ້ຍົກເວັ້ນດັ່ງກ່າວໃນບາງສ່ວນຂອງລະຫັດ, ທ່ານສາມາດຫໍ່ມັນຢູ່ໃນການໂທ. Thread.BeginCriticalRegion, Thread.EndCriticalRegion. ລະຫັດໃດໆທີ່ຂຽນຢູ່ໃນບລັອກສຸດທ້າຍແມ່ນຫໍ່ຢູ່ໃນການໂທດັ່ງກ່າວ. ສໍາລັບເຫດຜົນນີ້, ໃນຄວາມເລິກຂອງລະຫັດກອບ, ທ່ານສາມາດຊອກຫາຕັນດ້ວຍການພະຍາຍາມຫວ່າງເປົ່າ, ແຕ່ສຸດທ້າຍບໍ່ແມ່ນຫວ່າງເປົ່າ. Microsoft ຂັດຂວາງວິທີການນີ້ຫຼາຍທີ່ພວກເຂົາບໍ່ໄດ້ລວມເອົາມັນຢູ່ໃນ .net core.

ວິທີການຂັດຂວາງເຮັດວຽກທີ່ຄາດເດົາໄດ້ຫຼາຍຂຶ້ນ. ມັນສາມາດຂັດຂວາງກະທູ້ໂດຍມີຂໍ້ຍົກເວັ້ນ ThreadInterruptedException ພຽງແຕ່ໃນຊ່ວງເວລາເຫຼົ່ານັ້ນໃນເວລາທີ່ກະທູ້ຢູ່ໃນສະຖານະລໍຖ້າ. ມັນເຂົ້າສູ່ສະຖານະນີ້ໃນຂະນະທີ່ຫ້ອຍໃນຂະນະທີ່ລໍຖ້າ WaitHandle, lock, ຫຼືຫຼັງຈາກໂທຫາ Thread.Sleep.

ທັງສອງທາງເລືອກທີ່ອະທິບາຍຂ້າງເທິງແມ່ນບໍ່ດີເນື່ອງຈາກການຄາດເດົາບໍ່ໄດ້. ການແກ້ໄຂແມ່ນການນໍາໃຊ້ໂຄງສ້າງ CancellationToken ແລະຫ້ອງຮຽນ ແຫຼ່ງ CancellationToken. ຈຸດນີ້ແມ່ນ: ຕົວຢ່າງຂອງຊັ້ນ CancellationTokenSource ຖືກສ້າງຂື້ນແລະມີພຽງແຕ່ຜູ້ທີ່ເປັນເຈົ້າຂອງມັນເທົ່ານັ້ນທີ່ສາມາດຢຸດເຊົາການດໍາເນີນການໂດຍການໂທຫາວິທີການ. ຍົກເລີກການ. ພຽງແຕ່ CancellationToken ຖືກສົ່ງໄປຫາການດໍາເນີນງານຂອງມັນເອງ. ເຈົ້າຂອງ CancellationToken ບໍ່ສາມາດຍົກເລີກການດໍາເນີນການດ້ວຍຕົນເອງ, ແຕ່ພຽງແຕ່ສາມາດກວດເບິ່ງວ່າການດໍາເນີນງານໄດ້ຖືກຍົກເລີກ. ມີຄຸນສົມບັດ Boolean ສໍາລັບການນີ້ ຮ້ອງຂໍການຍົກເລີກແລ້ວ ແລະວິທີການ ຮ້ອງຂໍຍົກເລີກແລ້ວ. ສຸດທ້າຍຈະຖິ້ມຂໍ້ຍົກເວັ້ນ TaskCelledException ຖ້າວິທີການຍົກເລີກຖືກເອີ້ນຢູ່ໃນຕົວຢ່າງ CancellationToken ທີ່ຖືກ parroted. ແລະນີ້ແມ່ນວິທີການທີ່ຂ້ອຍແນະນໍາໃຫ້ໃຊ້. ນີ້​ແມ່ນ​ການ​ປັບ​ປຸງ​ທາງ​ເລືອກ​ທີ່​ຜ່ານ​ມາ​ໂດຍ​ການ​ໄດ້​ຮັບ​ການ​ຄວບ​ຄຸມ​ຢ່າງ​ເຕັມ​ທີ່​ໃນ​ຈຸດ​ໃດ​ທີ່​ການ​ປະ​ຕິ​ບັດ​ການ​ຍົກ​ເລີກ​ສາ​ມາດ​ຍົກ​ເລີກ.

ທາງເລືອກທີ່ໂຫດຮ້າຍທີ່ສຸດສໍາລັບການຢຸດກະທູ້ແມ່ນການໂທຫາຫນ້າທີ່ Win32 API TerminateThread. ພຶດຕິກໍາຂອງ CLR ຫຼັງຈາກການເອີ້ນຟັງຊັນນີ້ອາດຈະບໍ່ສາມາດຄາດເດົາໄດ້. ໃນ MSDN ຕໍ່ໄປນີ້ແມ່ນຂຽນກ່ຽວກັບຫນ້າທີ່ນີ້: "TerminateThread ແມ່ນຫນ້າທີ່ອັນຕະລາຍທີ່ຄວນຈະຖືກນໍາໃຊ້ໃນກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດເທົ່ານັ້ນ. “

ການປ່ຽນ API ເດີມເປັນ Task Based ໂດຍໃຊ້ວິທີ FromAsync

ຖ້າທ່ານໂຊກດີພໍທີ່ຈະເຮັດວຽກໃນໂຄງການທີ່ໄດ້ເລີ່ມຕົ້ນຫຼັງຈາກ Tasks ຖືກນໍາສະເຫນີແລະຢຸດເຊົາທີ່ຈະເຮັດໃຫ້ເກີດຄວາມຢ້ານທີ່ງຽບສະຫງົບສໍາລັບນັກພັດທະນາສ່ວນໃຫຍ່, ຫຼັງຈາກນັ້ນທ່ານຈະບໍ່ຕ້ອງຈັດການກັບ APIs ເກົ່າຫຼາຍ, ທັງພາກສ່ວນທີສາມແລະທີມງານຂອງທ່ານ. ໄດ້​ຖືກ​ທໍ​ລະ​ມານ​ໃນ​ອະ​ດີດ​. ໂຊກດີ, ທີມງານ .NET Framework ໄດ້ດູແລພວກເຮົາ, ເຖິງແມ່ນວ່າບາງທີເປົ້າຫມາຍແມ່ນເພື່ອດູແລຕົວເອງ. ຍ້ອນວ່າມັນອາດຈະ, .NET ມີເຄື່ອງມືຈໍານວນຫນຶ່ງສໍາລັບການແປງລະຫັດທີ່ບໍ່ເຈັບປວດທີ່ຂຽນໄວ້ໃນວິທີການການຂຽນໂປລແກລມ asynchronous ເກົ່າໄປຫາໃຫມ່. ຫນຶ່ງໃນນັ້ນແມ່ນວິທີການ FromAsync ຂອງ TaskFactory. ໃນຕົວຢ່າງລະຫັດຂ້າງລຸ່ມນີ້, ຂ້າພະເຈົ້າຫໍ່ວິທີການ async ເກົ່າຂອງຫ້ອງຮຽນ WebRequest ໃນ Task ໂດຍໃຊ້ວິທີນີ້.

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

ນີ້ແມ່ນພຽງແຕ່ຕົວຢ່າງແລະທ່ານບໍ່ຫນ້າຈະຕ້ອງເຮັດແບບນີ້ກັບປະເພດທີ່ສ້າງຂຶ້ນ, ແຕ່ໂຄງການເກົ່າໃດກໍ່ຕາມແມ່ນພຽງແຕ່ teeming ກັບວິທີການ BeginDoSomething ທີ່ກັບຄືນ IAsyncResult ແລະ EndDoSomething ວິທີການທີ່ໄດ້ຮັບມັນ.

ປ່ຽນ API ເດີມເປັນ Task Based ໂດຍໃຊ້ຄລາສ TaskCompletionSource

ເຄື່ອງມືທີ່ສໍາຄັນອີກອັນຫນຶ່ງທີ່ຈະພິຈາລະນາແມ່ນຫ້ອງຮຽນ TaskCompletionSource. ໃນຂໍ້ກໍານົດຂອງຫນ້າທີ່, ຈຸດປະສົງແລະຫຼັກການຂອງການດໍາເນີນງານ, ມັນອາດຈະເປັນການລະນຶກເຖິງວິທີການ RegisterWaitForSingleObject ຂອງຫ້ອງຮຽນ ThreadPool, ທີ່ຂ້າພະເຈົ້າໄດ້ຂຽນກ່ຽວກັບຂ້າງເທິງ. ການນໍາໃຊ້ຫ້ອງຮຽນນີ້, ທ່ານສາມາດຫໍ່ APIs asynchronous ເກົ່າໄດ້ຢ່າງງ່າຍດາຍແລະສະດວກໃນ Tasks.

ທ່ານຈະເວົ້າວ່າຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບວິທີການ FromAsync ຂອງຫ້ອງຮຽນ TaskFactory ທີ່ມີຈຸດປະສົງເພື່ອຈຸດປະສົງເຫຼົ່ານີ້. ໃນທີ່ນີ້ພວກເຮົາຈະຕ້ອງຈື່ປະຫວັດທັງຫມົດຂອງການພັດທະນາແບບ asynchronous ໃນ .net ທີ່ Microsoft ໄດ້ສະເຫນີໃນໄລຍະ 15 ປີທີ່ຜ່ານມາ: ກ່ອນທີ່ຈະ Task-Based Asynchronous Pattern (TAP), ມີ Asynchronous Programming Pattern (APP), ເຊິ່ງ. ແມ່ນກ່ຽວກັບວິທີການ ເລີ່ມຕົ້ນເຮັດບາງສິ່ງບາງຢ່າງກັບຄືນມາ IAsyncResult ແລະວິທີການ ສຸດທ້າຍDoSomething ທີ່ຍອມຮັບມັນແລະສໍາລັບມໍລະດົກຂອງປີເຫຼົ່ານີ້ວິທີການ FromAsync ແມ່ນພຽງແຕ່ທີ່ສົມບູນແບບ, ແຕ່ເມື່ອເວລາຜ່ານໄປ, ມັນຖືກປ່ຽນແທນດ້ວຍຮູບແບບ Asynchronous ເຫດການ (ແລະ AP), ເຊິ່ງສົມມຸດວ່າເຫດການຫນຶ່ງຈະຖືກຍົກຂຶ້ນມາເມື່ອການດໍາເນີນງານແບບ asynchronous ສໍາເລັດ.

TaskCompletionSource ແມ່ນດີເລີດສໍາລັບການຫໍ່ Tasks ແລະ APIs ເກົ່າທີ່ສ້າງຂຶ້ນປະມານຮູບແບບເຫດການ. ໂດຍເນື້ອແທ້ແລ້ວຂອງການເຮັດວຽກຂອງມັນແມ່ນດັ່ງນີ້: ວັດຖຸຂອງຫ້ອງຮຽນນີ້ມີຊັບສິນສາທາລະນະຂອງປະເພດ Task, ສະຖານະທີ່ສາມາດຄວບຄຸມໄດ້ໂດຍຜ່ານວິທີການ SetResult, SetException, ແລະອື່ນໆຂອງຫ້ອງຮຽນ TaskCompletionSource. ໃນສະຖານທີ່ທີ່ຕົວປະຕິບັດການລໍຖ້າຖືກນໍາໃຊ້ກັບວຽກງານນີ້, ມັນຈະຖືກປະຕິບັດຫຼືລົ້ມເຫລວໂດຍມີຂໍ້ຍົກເວັ້ນໂດຍອີງຕາມວິທີການນໍາໃຊ້ກັບ 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 Tips & Tricks

ການຫໍ່ APIs ເກົ່າບໍ່ແມ່ນທັງຫມົດທີ່ສາມາດເຮັດໄດ້ໂດຍໃຊ້ TaskCompletionSource. ການນໍາໃຊ້ຫ້ອງຮຽນນີ້ເປີດຄວາມເປັນໄປໄດ້ທີ່ຫນ້າສົນໃຈໃນການອອກແບບ APIs ຕ່າງໆໃນ Tasks ທີ່ບໍ່ຄອບຄອງກະທູ້. ແລະສາຍນ້ໍາ, ດັ່ງທີ່ພວກເຮົາຈື່, ເປັນຊັບພະຍາກອນທີ່ມີລາຄາແພງແລະຈໍານວນຂອງພວກເຂົາຖືກຈໍາກັດ (ສ່ວນໃຫຍ່ແມ່ນມາຈາກຈໍານວນ RAM). ຂໍ້ຈໍາກັດນີ້ສາມາດບັນລຸໄດ້ຢ່າງງ່າຍດາຍໂດຍການພັດທະນາ, ສໍາລັບຕົວຢ່າງ, ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ໂຫລດທີ່ມີເຫດຜົນທາງທຸລະກິດທີ່ສັບສົນ. ຂໍໃຫ້ພິຈາລະນາຄວາມເປັນໄປໄດ້ທີ່ຂ້ອຍເວົ້າກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດ trick ເຊັ່ນ Long-Polling.

ໃນສັ້ນ, ໂດຍເນື້ອແທ້ແລ້ວຂອງ trick ແມ່ນນີ້: ທ່ານຈໍາເປັນຕ້ອງໄດ້ຮັບຂໍ້ມູນຈາກ API ກ່ຽວກັບເຫດການບາງຢ່າງທີ່ເກີດຂື້ນຢູ່ຂ້າງຂອງມັນ, ໃນຂະນະທີ່ API, ສໍາລັບເຫດຜົນບາງຢ່າງ, ບໍ່ສາມາດລາຍງານເຫດການ, ແຕ່ສາມາດສົ່ງຄືນສະຖານະເທົ່ານັ້ນ. ຕົວຢ່າງຂອງການເຫຼົ່ານີ້ແມ່ນ APIs ທັງຫມົດທີ່ສ້າງຂຶ້ນຢູ່ເທິງສຸດຂອງ HTTP ກ່ອນເວລາຂອງ WebSocket ຫຼືເວລາທີ່ມັນເປັນໄປບໍ່ໄດ້ສໍາລັບເຫດຜົນບາງຢ່າງທີ່ຈະໃຊ້ເຕັກໂນໂລຢີນີ້. ລູກຄ້າສາມາດຖາມເຄື່ອງແມ່ຂ່າຍ HTTP. ເຊີບເວີ HTTP ບໍ່ສາມາດລິເລີ່ມການສື່ສານກັບລູກຄ້າໄດ້. ການແກ້ໄຂງ່າຍໆຄືການສຳຫຼວດເຊີບເວີໂດຍໃຊ້ເຄື່ອງຈັບເວລາ, ແຕ່ອັນນີ້ສ້າງການໂຫຼດເພີ່ມເຕີມໃນເຊີບເວີ ແລະຄວາມລ່າຊ້າເພີ່ມເຕີມໂດຍສະເລ່ຍ TimerInterval / 2. ເພື່ອເຮັດໃຫ້ປະມານນີ້, trick ທີ່ເອີ້ນວ່າ Long Polling ໄດ້ຖືກຄິດຄົ້ນ, ເຊິ່ງກ່ຽວຂ້ອງກັບການຊັກຊ້າການຕອບໂຕ້ຈາກ. ເຊີບເວີຈົນກ່ວາໝົດເວລາໝົດອາຍຸ ຫຼືເຫດການຈະເກີດຂຶ້ນ. ຖ້າເຫດການໄດ້ເກີດຂື້ນ, ຫຼັງຈາກນັ້ນມັນຖືກປຸງແຕ່ງ, ຖ້າບໍ່ແມ່ນ, ຫຼັງຈາກນັ້ນການຮ້ອງຂໍຈະຖືກສົ່ງອີກເທື່ອຫນຶ່ງ.

while(!eventOccures && !timeoutExceeded)  {

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

ແຕ່ການແກ້ໄຂດັ່ງກ່າວຈະພິສູດວ່າເປັນຂີ້ຮ້າຍທັນທີທີ່ຈໍານວນລູກຄ້າລໍຖ້າເຫດການເພີ່ມຂຶ້ນ, ເພາະວ່າ ... ແຕ່ລະລູກຄ້າດັ່ງກ່າວຄອບຄອງກະທູ້ທັງຫມົດລໍຖ້າເຫດການ. ແມ່ນແລ້ວ, ແລະພວກເຮົາໄດ້ຮັບຄວາມລ່າຊ້າ 1ms ເພີ່ມເຕີມເມື່ອເຫດການຖືກກະຕຸ້ນ, ສ່ວນຫຼາຍມັກຈະບໍ່ສໍາຄັນ, ແຕ່ເປັນຫຍັງເຮັດໃຫ້ຊອບແວຮ້າຍແຮງກວ່າທີ່ມັນເປັນໄປໄດ້? ຖ້າພວກເຮົາເອົາ Thread.Sleep(1), ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະໂຫລດຫຼັກຂອງໂປເຊດເຊີຫນຶ່ງ 100% ບໍ່ໄດ້ເຮັດວຽກ, rotating ໃນວົງຈອນທີ່ບໍ່ມີປະໂຫຍດ. ການນໍາໃຊ້ TaskCompletionSource ທ່ານສາມາດ remake ລະຫັດນີ້ໄດ້ຢ່າງງ່າຍດາຍແລະແກ້ໄຂບັນຫາທັງຫມົດທີ່ລະບຸໄວ້ຂ້າງເທິງນີ້:

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 / ລໍຖ້າ, ຄືກັບຕົວປະຕິບັດການກັບຄືນຜົນຜະລິດ, ສ້າງເຄື່ອງຈັກຂອງລັດຈາກວິທີການ, ແລະນີ້ແມ່ນການສ້າງວັດຖຸໃຫມ່, ເຊິ່ງເກືອບສະເຫມີບໍ່ສໍາຄັນ, ແຕ່ໃນກໍລະນີທີ່ຫາຍາກມັນກໍ່ສາມາດສ້າງບັນຫາໄດ້. ກໍລະນີນີ້ອາດຈະເປັນວິທີການທີ່ເອີ້ນວ່າເລື້ອຍໆ, ພວກເຮົາກໍາລັງເວົ້າເຖິງຫຼາຍສິບແລະຫຼາຍຮ້ອຍພັນການໂທຕໍ່ວິນາທີ. ຖ້າວິທີການດັ່ງກ່າວຖືກຂຽນໄວ້ໃນລັກສະນະດັ່ງກ່າວ, ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ມັນຈະສົ່ງຄືນຜົນໄດ້ຮັບທີ່ຂ້າມວິທີການລໍຖ້າທັງຫມົດ, ຫຼັງຈາກນັ້ນ .NET ສະຫນອງເຄື່ອງມືເພື່ອເພີ່ມປະສິດທິພາບນີ້ - ໂຄງສ້າງ ValueTask . ເພື່ອເຮັດໃຫ້ມັນຊັດເຈນ, ໃຫ້ເບິ່ງຕົວຢ່າງຂອງການນໍາໃຊ້ຂອງມັນ: ມີ cache ທີ່ພວກເຮົາໄປຫາເລື້ອຍໆ. ມີມູນຄ່າບາງຢ່າງຢູ່ໃນນັ້ນແລະຫຼັງຈາກນັ້ນພວກເຮົາພຽງແຕ່ສົ່ງຄືນໃຫ້ເຂົາເຈົ້າ; ຂ້ອຍຕ້ອງການເຮັດແບບບໍ່ກົງກັນ, ຊຶ່ງຫມາຍຄວາມວ່າວິທີການທັງຫມົດຈະກາຍເປັນບໍ່ຊິ້ງ. ດັ່ງນັ້ນ, ວິທີທີ່ຈະແຈ້ງໃນການຂຽນວິທີການແມ່ນດັ່ງຕໍ່ໄປນີ້:

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

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບຊິ້ນສ່ວນຂອງລະຫັດນີ້: ຖ້າມີມູນຄ່າໃນ cache, ພວກເຮົາສ້າງໂຄງສ້າງ, ຖ້າບໍ່ດັ່ງນັ້ນວຽກງານທີ່ແທ້ຈິງຈະຖືກຫໍ່ດ້ວຍຄວາມຫມາຍ. ລະຫັດການໂທບໍ່ສົນໃຈເສັ້ນທາງໃດທີ່ລະຫັດນີ້ຖືກປະຕິບັດໃນ: ValueTask, ຈາກຈຸດຂອງ syntax C#, ຈະປະຕິບັດຄືກັນກັບ Task ປົກກະຕິໃນກໍລະນີນີ້.

TaskSchedulers: ການຄຸ້ມຄອງຍຸດທະສາດການເປີດຕົວວຽກງານ

API ຕໍ່ໄປທີ່ຂ້ອຍຢາກພິຈາລະນາແມ່ນຫ້ອງຮຽນ TaskScheduler ແລະອະນຸພັນຂອງມັນ. ຂ້າພະເຈົ້າໄດ້ກ່າວມາແລ້ວຂ້າງເທິງວ່າ TPL ມີຄວາມສາມາດໃນການຄຸ້ມຄອງຍຸດທະສາດການແຈກຢາຍວຽກງານໃນທົ່ວກະທູ້. ຍຸດທະສາດດັ່ງກ່າວຖືກກໍານົດຢູ່ໃນລູກຫລານຂອງຊັ້ນ TaskScheduler. ເກືອບທຸກຍຸດທະສາດທີ່ເຈົ້າອາດຈະຕ້ອງການສາມາດພົບໄດ້ໃນຫ້ອງສະໝຸດ. ParallelExtensionsExtras, ພັດທະນາໂດຍ Microsoft, ແຕ່ບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງ .NET, ແຕ່ສະຫນອງໃຫ້ເປັນຊຸດ Nuget. ຂໍ​ໃຫ້​ເບິ່ງ​ບາງ​ຢ່າງ​ໂດຍ​ຫຍໍ້​ຂອງ​ພວກ​ເຂົາ​:

• CurrentThreadTaskScheduler — ປະ​ຕິ​ບັດ​ວຽກ​ງານ​ກ່ຽວ​ກັບ​ກະ​ທູ້​ປະ​ຈຸ​ບັນ​
• LimitedConcurrencyLevelTaskScheduler - ຈໍາ​ກັດ​ຈໍາ​ນວນ​ຂອງ​ຫນ້າ​ວຽກ​ທີ່​ປະ​ຕິ​ບັດ​ພ້ອມ​ກັນ​ໂດຍ​ພາ​ຣາ​ມິ​ເຕີ N​, ທີ່​ຖືກ​ຍອມ​ຮັບ​ໃນ constructor
• OrderedTaskScheduler — ຖືກກໍານົດເປັນ LimitedConcurrencyLevelTaskScheduler(1), ດັ່ງນັ້ນວຽກງານຈະຖືກປະຕິບັດຕາມລໍາດັບ.
• WorkStealingTaskScheduler - ປະຕິບັດ ການລັກເຮັດວຽກ ວິທີການແຈກຢາຍວຽກງານ. ໂດຍພື້ນຖານແລ້ວມັນແມ່ນ ThreadPool ແຍກຕ່າງຫາກ. ແກ້ໄຂບັນຫາທີ່ໃນ .NET ThreadPool ເປັນຫ້ອງຮຽນ static, ຫນຶ່ງສໍາລັບຄໍາຮ້ອງສະຫມັກທັງຫມົດ, ຊຶ່ງຫມາຍຄວາມວ່າການ overloading ຫຼືການນໍາໃຊ້ບໍ່ຖືກຕ້ອງໃນສ່ວນຫນຶ່ງຂອງໂຄງການສາມາດນໍາໄປສູ່ການຜົນຂ້າງຄຽງໃນອີກ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນການຍາກທີ່ສຸດທີ່ຈະເຂົ້າໃຈສາເຫດຂອງຂໍ້ບົກພ່ອງດັ່ງກ່າວ. ນັ້ນ. ອາດຈະຈໍາເປັນຕ້ອງໃຊ້ WorkStealingTaskSchedulers ແຍກຕ່າງຫາກໃນສ່ວນຕ່າງໆຂອງໂປລແກລມທີ່ການນໍາໃຊ້ ThreadPool ອາດຈະຮຸກຮານແລະບໍ່ສາມາດຄາດເດົາໄດ້.
• QueuedTaskScheduler — ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ປະ​ຕິ​ບັດ​ວຽກ​ງານ​ຕາມ​ກົດ​ລະ​ບຽບ​ແຖວ​ບູ​ລິ​ມະ​ສິດ​
• ThreadPerTaskScheduler — ສ້າງກະທູ້ແຍກຕ່າງຫາກສໍາລັບແຕ່ລະ Task ທີ່ຖືກປະຕິບັດຢູ່ໃນມັນ. ສາມາດເປັນປະໂຫຍດສໍາລັບວຽກງານທີ່ໃຊ້ເວລາດົນ unpredictable ທີ່ຈະສໍາເລັດ.

ມີລາຍລະອຽດທີ່ດີ ບົດຄວາມ ກ່ຽວກັບ TaskSchedulers ໃນ blog microsoft.

ສຳລັບການດີບັກທີ່ສະດວກຂອງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ Tasks, Visual Studio ມີໜ້າຕ່າງ Tasks. ຢູ່ໃນປ່ອງຢ້ຽມນີ້, ທ່ານສາມາດເບິ່ງສະຖານະການປະຈຸບັນຂອງຫນ້າວຽກແລະເຕັ້ນໄປຫາເສັ້ນປະຕິບັດປະຈຸບັນຂອງລະຫັດ.

PLinq ແລະຫ້ອງຮຽນຂະຫນານ

ນອກເຫນືອໄປຈາກ Tasks ແລະທຸກສິ່ງທຸກຢ່າງທີ່ເວົ້າກ່ຽວກັບພວກມັນ, ມີສອງເຄື່ອງມືທີ່ຫນ້າສົນໃຈຫຼາຍໃນ .NET: PLinq (Linq2Parallel) ແລະຫ້ອງຮຽນຂະຫນານ. ທໍາອິດສັນຍາການປະຕິບັດຂະຫນານຂອງການດໍາເນີນງານ Linq ທັງຫມົດໃນຫຼາຍຫົວຂໍ້. ຈໍານວນກະທູ້ສາມາດຖືກຕັ້ງຄ່າໂດຍໃຊ້ວິທີການຂະຫຍາຍ WithDegreeOfParallelism. ແຕ່ຫນ້າເສຍດາຍ, ສ່ວນຫຼາຍມັກ, PLinq ໃນຮູບແບບເລີ່ມຕົ້ນຂອງມັນບໍ່ມີຂໍ້ມູນພຽງພໍກ່ຽວກັບພາຍໃນຂອງແຫຼ່ງຂໍ້ມູນຂອງທ່ານເພື່ອໃຫ້ໄດ້ຄວາມໄວທີ່ສໍາຄັນ, ໃນທາງກົງກັນຂ້າມ, ຄ່າໃຊ້ຈ່າຍຂອງຄວາມພະຍາຍາມແມ່ນຕໍ່າຫຼາຍ: ທ່ານພຽງແຕ່ຕ້ອງການໂທຫາວິທີການ AsParallel ກ່ອນ. ລະບົບຕ່ອງໂສ້ຂອງວິທີການ Linq ແລະດໍາເນີນການທົດສອບປະສິດທິພາບ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນໄປໄດ້ທີ່ຈະສົ່ງຂໍ້ມູນເພີ່ມເຕີມໃຫ້ PLinq ກ່ຽວກັບລັກສະນະຂອງແຫຼ່ງຂໍ້ມູນຂອງທ່ານໂດຍໃຊ້ກົນໄກການແບ່ງສ່ວນ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມ ທີ່ນີ້ и ທີ່ນີ້.

Parallel static class ສະໜອງວິທີການສໍາລັບການ iterating ໂດຍຜ່ານ Foreach collection ໃນຂະຫນານ, ປະຕິບັດສໍາລັບ loop, ແລະປະຕິບັດຕົວແທນຫຼາຍໃນຂະຫນານ Invoke. ການປະຕິບັດກະທູ້ປະຈຸບັນຈະຖືກຢຸດຈົນກ່ວາການຄິດໄລ່ສໍາເລັດ. ຈໍາ​ນວນ​ຂອງ​ກະ​ທູ້​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​ໂດຍ​ການ​ຜ່ານ ParallelOptions ເປັນ​ການ​ໂຕ້​ຖຽງ​ສຸດ​ທ້າຍ​. ທ່ານຍັງສາມາດລະບຸ TaskScheduler ແລະ CancellationToken ໂດຍໃຊ້ຕົວເລືອກຕ່າງໆ.

ການຄົ້ນພົບ

ເມື່ອຂ້ອຍເລີ່ມຂຽນບົດຄວາມນີ້ໂດຍອີງໃສ່ເອກະສານຂອງບົດລາຍງານຂອງຂ້ອຍແລະຂໍ້ມູນທີ່ຂ້ອຍເກັບກໍາໃນລະຫວ່າງການເຮັດວຽກຂອງຂ້ອຍຫຼັງຈາກມັນ, ຂ້ອຍບໍ່ໄດ້ຄາດຫວັງວ່າຈະມີຫຼາຍ. ໃນປັດຈຸບັນ, ໃນເວລາທີ່ບັນນາທິການຂໍ້ຄວາມທີ່ຂ້າພະເຈົ້າພິມບົດຄວາມນີ້ reproachfully ບອກຂ້າພະເຈົ້າວ່າຫນ້າ 15 ໄດ້ຫມົດໄປ, ຂ້າພະເຈົ້າຈະສະຫຼຸບຜົນໄດ້ຮັບຊົ່ວຄາວ. tricks ອື່ນໆ, APIs, ເຄື່ອງມືສາຍຕາແລະ pitfalls ຈະໄດ້ຮັບການກວມເອົາໃນບົດຄວາມຕໍ່ໄປ.

ຂໍ້ສະຫຼຸບ:

• ທ່ານຈໍາເປັນຕ້ອງຮູ້ເຄື່ອງມືສໍາລັບການເຮັດວຽກກັບກະທູ້, asynchrony ແລະຂະຫນານເພື່ອນໍາໃຊ້ຊັບພະຍາກອນຂອງເຄື່ອງຄອມພິວເຕີທີ່ທັນສະໄຫມ.
• .NET ມີເຄື່ອງມືທີ່ແຕກຕ່າງກັນຫຼາຍສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້
• ບໍ່ແມ່ນພວກມັນທັງຫມົດປາກົດຢູ່ໃນເວລາດຽວ, ດັ່ງນັ້ນທ່ານມັກຈະສາມາດຊອກຫາມໍລະດົກ, ຢ່າງໃດກໍຕາມ, ມີວິທີທີ່ຈະປ່ຽນ APIs ເກົ່າໂດຍບໍ່ຕ້ອງໃຊ້ຄວາມພະຍາຍາມຫຼາຍ.
• ການເຮັດວຽກກັບກະທູ້ໃນ .NET ແມ່ນສະແດງໂດຍຫ້ອງຮຽນ Thread ແລະ ThreadPool
• ວິທີການ Thread.Abort, Thread.Interrupt, ແລະ Win32 API TerminateThread ແມ່ນອັນຕະລາຍ ແລະບໍ່ໄດ້ຖືກແນະນຳໃຫ້ໃຊ້. ແທນທີ່ຈະ, ມັນດີກວ່າທີ່ຈະໃຊ້ກົນໄກ CancellationToken
• ການໄຫຼເຂົ້າເປັນຊັບພະຍາກອນທີ່ມີຄຸນຄ່າແລະການສະຫນອງຂອງມັນແມ່ນຈໍາກັດ. ສະຖານະການທີ່ກະທູ້ບໍ່ຫວ່າງລໍຖ້າເຫດການຄວນຫຼີກເວັ້ນ. ສໍາລັບການນີ້ມັນສະດວກທີ່ຈະນໍາໃຊ້ຫ້ອງຮຽນ TaskCompletionSource
• ເຄື່ອງມື .NET ທີ່ມີປະສິດທິພາບ ແລະກ້າວໜ້າທີ່ສຸດສຳລັບການເຮັດວຽກກັບຂະໜານ ແລະແບບບໍ່ກົງກັນແມ່ນ Tasks.
• ຜູ້ປະຕິບັດການ c# async/await ປະຕິບັດແນວຄວາມຄິດຂອງການລໍຖ້າທີ່ບໍ່ມີການຂັດຂວາງ
• ທ່ານສາມາດຄວບຄຸມການແຈກຢາຍ Tasks ໃນທົ່ວຫົວຂໍ້ໂດຍໃຊ້ TaskScheduler-derived classes
• ໂຄງສ້າງ ValueTask ສາມາດເປັນປະໂຫຍດໃນການເພີ່ມປະສິດທິພາບເສັ້ນທາງຮ້ອນ ແລະ memory-traffic
• ໜ້າຕ່າງໜ້າວຽກ ແລະກະທູ້ຂອງ Visual Studio ສະໜອງຂໍ້ມູນຫຼາຍຢ່າງທີ່ເປັນປະໂຫຍດສຳລັບການດີບັກຫຼາຍກະທູ້ ຫຼື ລະຫັດບໍ່ຊິ້ງ.
• PLinq ເປັນ​ເຄື່ອງ​ມື​ທີ່​ເຢັນ​, ແຕ່​ວ່າ​ມັນ​ອາດ​ຈະ​ບໍ່​ມີ​ຂໍ້​ມູນ​ພຽງ​ພໍ​ກ່ຽວ​ກັບ​ແຫຼ່ງ​ຂໍ້​ມູນ​ຂອງ​ທ່ານ​, ແຕ່​ນີ້​ສາ​ມາດ​ແກ້​ໄຂ​ໄດ້​ໂດຍ​ນໍາ​ໃຊ້​ກົນ​ໄກ​ການ​ແບ່ງ​ປັນ​.
• ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ…

ແຫຼ່ງຂໍ້ມູນ: www.habr.com