.NET: മൾട്ടിത്രെഡിംഗും അസിൻക്രണിയും ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതിനുള്ള ഉപകരണങ്ങൾ. ഭാഗം 1

ഹബ്റിനെക്കുറിച്ചുള്ള യഥാർത്ഥ ലേഖനം ഞാൻ പ്രസിദ്ധീകരിക്കുന്നു, അതിന്റെ വിവർത്തനം കോർപ്പറേറ്റിൽ പോസ്റ്റ് ചെയ്തിട്ടുണ്ട് ബ്ലോഗ് പോസ്റ്റ്.

ഇവിടെയും ഇപ്പോളും ഫലത്തിനായി കാത്തിരിക്കാതെ, അല്ലെങ്കിൽ അത് ചെയ്യുന്ന നിരവധി യൂണിറ്റുകൾക്കിടയിൽ വലിയ ജോലികൾ വിഭജിക്കാതെ, അസമന്വിതമായി എന്തെങ്കിലും ചെയ്യേണ്ടതിന്റെ ആവശ്യകത കമ്പ്യൂട്ടറുകളുടെ ആവിർഭാവത്തിന് മുമ്പ് നിലവിലുണ്ടായിരുന്നു. അവരുടെ വരവോടെ, ഈ ആവശ്യം വളരെ മൂർത്തമായി. ഇപ്പോൾ, 2019-ൽ, 8-കോർ ഇന്റൽ കോർ പ്രോസസറുള്ള ഒരു ലാപ്‌ടോപ്പിൽ ഞാൻ ഈ ലേഖനം ടൈപ്പ് ചെയ്യുന്നു, അതിൽ നൂറിലധികം പ്രോസസ്സുകൾ സമാന്തരമായി പ്രവർത്തിക്കുന്നു, അതിലും കൂടുതൽ ത്രെഡുകൾ. സമീപത്ത്, കുറച്ച് ശോഷിച്ച ഫോൺ ഉണ്ട്, കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് വാങ്ങിയതാണ്, അതിൽ 8-കോർ പ്രൊസസർ ഉണ്ട്. 16-കോർ പ്രോസസറുകൾ ഫീച്ചർ ചെയ്യുന്ന ഈ വർഷത്തെ മുൻനിര സ്മാർട്ട്‌ഫോണുകളെ അവരുടെ രചയിതാക്കൾ അഭിനന്ദിക്കുന്ന ലേഖനങ്ങളും വീഡിയോകളും തീമാറ്റിക് ഉറവിടങ്ങളിൽ നിറഞ്ഞിരിക്കുന്നു. MS Azure 20 കോർ പ്രൊസസറും 128 TB റാമും ഉള്ള ഒരു വെർച്വൽ മെഷീൻ $2/മണിക്കൂറിൽ താഴെ നൽകുന്നു. നിർഭാഗ്യവശാൽ, ത്രെഡുകളുടെ ഇടപെടൽ നിയന്ത്രിക്കാൻ കഴിയാതെ പരമാവധി എക്‌സ്‌ട്രാക്റ്റുചെയ്യാനും ഈ ശക്തി പ്രയോജനപ്പെടുത്താനും കഴിയില്ല.

പദാവലി

പ്രക്രിയ - OS ഒബ്ജക്റ്റ്, ഒറ്റപ്പെട്ട വിലാസ ഇടം, ത്രെഡുകൾ അടങ്ങിയിരിക്കുന്നു.
ത്രെഡ് - ഒരു OS ഒബ്‌ജക്റ്റ്, എക്‌സിക്യൂഷന്റെ ഏറ്റവും ചെറിയ യൂണിറ്റ്, ഒരു പ്രക്രിയയുടെ ഭാഗം, ത്രെഡുകൾ ഒരു പ്രോസസ്സിനുള്ളിൽ മെമ്മറിയും മറ്റ് ഉറവിടങ്ങളും പരസ്പരം പങ്കിടുന്നു.
മൾട്ടിടാസ്കിംഗ് - OS പ്രോപ്പർട്ടി, ഒരേസമയം നിരവധി പ്രക്രിയകൾ പ്രവർത്തിപ്പിക്കാനുള്ള കഴിവ്
മൾട്ടി-കോർ - പ്രോസസ്സറിന്റെ ഒരു പ്രോപ്പർട്ടി, ഡാറ്റ പ്രോസസ്സിംഗിനായി നിരവധി കോറുകൾ ഉപയോഗിക്കാനുള്ള കഴിവ്
മൾട്ടിപ്രോസസിംഗ് - ഒരു കമ്പ്യൂട്ടറിന്റെ ഒരു പ്രോപ്പർട്ടി, ശാരീരികമായി നിരവധി പ്രോസസ്സറുകളുമായി ഒരേസമയം പ്രവർത്തിക്കാനുള്ള കഴിവ്
മൾട്ടിത്രെഡിംഗ് - ഒരു പ്രക്രിയയുടെ സ്വത്ത്, നിരവധി ത്രെഡുകൾക്കിടയിൽ ഡാറ്റ പ്രോസസ്സിംഗ് വിതരണം ചെയ്യാനുള്ള കഴിവ്.
സമാന്തരവാദം - ഒരു യൂണിറ്റ് സമയത്തിന് ഒരേസമയം ശാരീരികമായി നിരവധി പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു
അസമന്വിതം - ഈ പ്രോസസ്സിംഗ് പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കാതെ ഒരു ഓപ്പറേഷൻ നടപ്പിലാക്കുക; നിർവ്വഹണത്തിന്റെ ഫലം പിന്നീട് പ്രോസസ്സ് ചെയ്യാം.

ഭാവാര്ത്ഥം

എല്ലാ നിർവചനങ്ങളും നല്ലതല്ല, ചിലതിന് അധിക വിശദീകരണം ആവശ്യമാണ്, അതിനാൽ ഞാൻ ഔപചാരികമായി അവതരിപ്പിച്ച പദാവലിയിലേക്ക് പ്രഭാതഭക്ഷണം പാചകം ചെയ്യുന്നതിനെക്കുറിച്ച് ഒരു രൂപകം ചേർക്കും. ഈ രൂപകത്തിൽ പ്രഭാതഭക്ഷണം പാചകം ചെയ്യുന്നത് ഒരു പ്രക്രിയയാണ്.

രാവിലെ പ്രാതൽ തയ്യാറാക്കുമ്പോൾ ഞാൻ (സിപിയുഞാൻ അടുക്കളയിലേക്ക് വരുന്നു (കമ്പ്യൂട്ടർ). എനിക്ക് 2 കൈകളുണ്ട് (പാളികളിൽ). അടുക്കളയിൽ നിരവധി ഉപകരണങ്ങൾ ഉണ്ട് (IO): ഓവൻ, കെറ്റിൽ, ടോസ്റ്റർ, റഫ്രിജറേറ്റർ. ഞാൻ ഗ്യാസ് ഓണാക്കി, അതിൽ ഒരു ഫ്രൈയിംഗ് പാൻ ഇട്ടു, അത് ചൂടാകുന്നതുവരെ കാത്തിരിക്കാതെ അതിൽ എണ്ണ ഒഴിക്കുക (അസമന്വിതമായി, നോൺ-ബ്ലോക്കിംഗ്-ഐഒ-വെയ്റ്റ്), ഞാൻ റഫ്രിജറേറ്ററിൽ നിന്ന് മുട്ടകൾ എടുത്ത് ഒരു പ്ലേറ്റിലേക്ക് പൊട്ടിച്ച് ഒരു കൈകൊണ്ട് അടിക്കുക (ത്രെഡ്#1), രണ്ടാമത്തേത് (ത്രെഡ്#2) പ്ലേറ്റ് പിടിച്ച് (പങ്കിട്ട വിഭവം). ഇപ്പോൾ ഞാൻ കെറ്റിൽ ഓണാക്കാൻ ആഗ്രഹിക്കുന്നു, പക്ഷേ എനിക്ക് വേണ്ടത്ര കൈകളില്ല (ത്രെഡ് പട്ടിണി) ഈ സമയത്ത്, വറുത്ത പാൻ ചൂടാക്കുന്നു (ഫലം പ്രോസസ്സ് ചെയ്യുന്നു) അതിൽ ഞാൻ ചമ്മട്ടിയെടുത്തത് ഒഴിക്കുക. ഞാൻ കെറ്റിൽ എത്തി അത് ഓണാക്കി അതിൽ വെള്ളം തിളയ്ക്കുന്നത് മണ്ടത്തരമായി കാണുന്നു (തടയൽ-IO-കാത്തിരിക്കുക), ഈ സമയത്ത് അയാൾക്ക് ഓംലെറ്റ് അടിച്ച പ്ലേറ്റ് കഴുകാമായിരുന്നു.

ഞാൻ 2 കൈകൾ മാത്രം ഉപയോഗിച്ച് ഒരു ഓംലെറ്റ് പാകം ചെയ്തു, എനിക്ക് കൂടുതൽ ഇല്ല, എന്നാൽ അതേ സമയം, ഓംലെറ്റ് അടിച്ച നിമിഷത്തിൽ, ഒരേസമയം 3 ഓപ്പറേഷനുകൾ നടന്നു: ഓംലെറ്റ് അടിക്കുക, പ്ലേറ്റ് പിടിക്കുക, വറചട്ടി ചൂടാക്കുക കമ്പ്യൂട്ടറിന്റെ ഏറ്റവും വേഗതയേറിയ ഭാഗമാണ് സിപിയു, മിക്കപ്പോഴും എല്ലാം മന്ദഗതിയിലാകുന്നത് ഐഒയാണ്, അതിനാൽ ഐഒയിൽ നിന്ന് ഡാറ്റ സ്വീകരിക്കുമ്പോൾ സിപിയു എന്തെങ്കിലും ഉപയോഗിച്ച് കൈവശപ്പെടുത്തുക എന്നതാണ് പലപ്പോഴും ഫലപ്രദമായ പരിഹാരം.

രൂപകം തുടരുന്നു:

• ഒരു ഓംലെറ്റ് തയ്യാറാക്കുന്ന പ്രക്രിയയിൽ, ഞാൻ വസ്ത്രം മാറ്റാൻ ശ്രമിക്കുകയാണെങ്കിൽ, ഇത് മൾട്ടിടാസ്കിംഗിന്റെ ഒരു ഉദാഹരണമായിരിക്കും. ഒരു പ്രധാന ന്യൂനൻസ്: കമ്പ്യൂട്ടറുകൾ ഇതിൽ ആളുകളേക്കാൾ വളരെ മികച്ചതാണ്.
• നിരവധി പാചകക്കാരുള്ള ഒരു അടുക്കള, ഉദാഹരണത്തിന് ഒരു റെസ്റ്റോറന്റിൽ - ഒരു മൾട്ടി-കോർ കമ്പ്യൂട്ടർ.
• ഒരു ഷോപ്പിംഗ് സെന്ററിലെ ഫുഡ് കോർട്ടിലെ നിരവധി റെസ്റ്റോറന്റുകൾ - ഡാറ്റാ സെന്റർ

.NET ടൂളുകൾ

.NET മറ്റ് പല കാര്യങ്ങളും പോലെ ത്രെഡുകളുമായി പ്രവർത്തിക്കാൻ നല്ലതാണ്. ഓരോ പുതിയ പതിപ്പിലും, അവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള കൂടുതൽ കൂടുതൽ പുതിയ ടൂളുകൾ, OS ത്രെഡുകളിലൂടെ അമൂർത്തതയുടെ പുതിയ പാളികൾ ഇത് അവതരിപ്പിക്കുന്നു. അമൂർത്തങ്ങളുടെ നിർമ്മാണവുമായി പ്രവർത്തിക്കുമ്പോൾ, ഫ്രെയിംവർക്ക് ഡെവലപ്പർമാർ ഒരു സമീപനം ഉപയോഗിക്കുന്നു, ഉയർന്ന തലത്തിലുള്ള അമൂർത്തീകരണം ഉപയോഗിക്കുമ്പോൾ, ഒന്നോ അതിലധികമോ ലെവലുകൾ താഴേക്ക് പോകാനുള്ള അവസരം നൽകുന്നു. മിക്കപ്പോഴും ഇത് ആവശ്യമില്ല, വാസ്തവത്തിൽ ഇത് ഒരു ഷോട്ട്ഗൺ ഉപയോഗിച്ച് കാലിൽ സ്വയം വെടിവയ്ക്കാനുള്ള വാതിൽ തുറക്കുന്നു, എന്നാൽ ചിലപ്പോൾ, അപൂർവ സന്ദർഭങ്ങളിൽ, നിലവിലെ അമൂർത്തീകരണ തലത്തിൽ പരിഹരിക്കപ്പെടാത്ത ഒരു പ്രശ്നം പരിഹരിക്കാനുള്ള ഒരേയൊരു മാർഗ്ഗമാണിത്. .

ടൂളുകൾ കൊണ്ട്, ഞാൻ ഉദ്ദേശിക്കുന്നത് ഫ്രെയിംവർക്കും മൂന്നാം കക്ഷി പാക്കേജുകളും നൽകുന്ന രണ്ട് ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിംഗ് ഇന്റർഫേസുകളും (API-കളും), മൾട്ടി-ത്രെഡഡ് കോഡുമായി ബന്ധപ്പെട്ട എന്തെങ്കിലും പ്രശ്നങ്ങൾക്കുള്ള തിരയൽ ലളിതമാക്കുന്ന മുഴുവൻ സോഫ്‌റ്റ്‌വെയർ പരിഹാരങ്ങളും.

ഒരു ത്രെഡ് ആരംഭിക്കുന്നു

ത്രെഡുകളിൽ പ്രവർത്തിക്കുന്നതിനുള്ള .NET ലെ ഏറ്റവും അടിസ്ഥാന ക്ലാസാണ് ത്രെഡ് ക്ലാസ്. കൺസ്ട്രക്റ്റർ രണ്ട് പ്രതിനിധികളിൽ ഒരാളെ സ്വീകരിക്കുന്നു:

• ത്രെഡ്സ്റ്റാർട്ട് - പരാമീറ്ററുകളൊന്നുമില്ല
• ParametrizedThreadStart - തരം ഒബ്‌ജക്‌റ്റിന്റെ ഒരു പാരാമീറ്ററിനൊപ്പം.

സ്റ്റാർട്ട് മെത്തേഡ് വിളിച്ചതിന് ശേഷം ഡെലിഗേറ്റ് പുതുതായി സൃഷ്‌ടിച്ച ത്രെഡിൽ എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടും. ParametrizedThreadStart ടൈപ്പിന്റെ ഒരു ഡെലിഗേറ്റ് കൺസ്‌ട്രക്‌ടറിന് കൈമാറിയെങ്കിൽ, ഒരു ഒബ്‌ജക്റ്റ് ആരംഭ രീതിയിലേക്ക് കൈമാറണം. ഏതെങ്കിലും പ്രാദേശിക വിവരങ്ങൾ സ്ട്രീമിലേക്ക് കൈമാറാൻ ഈ സംവിധാനം ആവശ്യമാണ്. ഒരു ത്രെഡ് സൃഷ്‌ടിക്കുന്നത് ചെലവേറിയ പ്രവർത്തനമാണെന്നും, ത്രെഡ് തന്നെ ഒരു ഭാരമേറിയ ഒബ്‌ജക്റ്റ് ആണെന്നും ശ്രദ്ധിക്കേണ്ടതാണ്, കാരണം ഇത് സ്റ്റാക്കിൽ 1MB മെമ്മറി അനുവദിക്കുകയും OS API- യുമായി ഇടപെടൽ ആവശ്യമാണ്.

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

ThreadPool ക്ലാസ് ഒരു പൂൾ എന്ന ആശയത്തെ പ്രതിനിധീകരിക്കുന്നു. .NET-ൽ, ത്രെഡ് പൂൾ എഞ്ചിനീയറിംഗിന്റെ ഒരു ഭാഗമാണ്, കൂടാതെ മൈക്രോസോഫ്റ്റിലെ ഡെവലപ്പർമാർ അത് വൈവിധ്യമാർന്ന സാഹചര്യങ്ങളിൽ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ വളരെയധികം പരിശ്രമിച്ചിട്ടുണ്ട്.

പൊതുവായ ആശയം:

ആപ്ലിക്കേഷൻ ആരംഭിക്കുന്ന നിമിഷം മുതൽ, പശ്ചാത്തലത്തിൽ റിസർവിൽ നിരവധി ത്രെഡുകൾ സൃഷ്ടിക്കുകയും അവ ഉപയോഗത്തിനായി എടുക്കാനുള്ള കഴിവ് നൽകുകയും ചെയ്യുന്നു. ത്രെഡുകൾ ഇടയ്ക്കിടെയും വലിയ അളവിലും ഉപയോഗിക്കുകയാണെങ്കിൽ, വിളിക്കുന്നയാളുടെ ആവശ്യങ്ങൾ നിറവേറ്റുന്നതിനായി പൂൾ വികസിക്കുന്നു. ശരിയായ സമയത്ത് പൂളിൽ സൗജന്യ ത്രെഡുകൾ ഇല്ലെങ്കിൽ, അത് ഒന്നുകിൽ ത്രെഡുകളിലൊന്ന് തിരികെ വരുന്നതിനായി കാത്തിരിക്കും, അല്ലെങ്കിൽ പുതിയതൊന്ന് സൃഷ്ടിക്കും. ചില ഹ്രസ്വകാല പ്രവർത്തനങ്ങൾക്ക് ത്രെഡ് പൂൾ മികച്ചതാണെന്നും ആപ്ലിക്കേഷന്റെ മുഴുവൻ പ്രവർത്തനത്തിലുടനീളം സേവനങ്ങളായി പ്രവർത്തിക്കുന്ന പ്രവർത്തനങ്ങൾക്ക് അനുയോജ്യമല്ലെന്നും ഇത് പിന്തുടരുന്നു.

പൂളിൽ നിന്ന് ഒരു ത്രെഡ് ഉപയോഗിക്കുന്നതിന്, WaitCallback തരത്തിന്റെ ഒരു പ്രതിനിധിയെ സ്വീകരിക്കുന്ന ഒരു QueueUserWorkItem രീതിയുണ്ട്, അതിന് ParametrizedThreadStart-ന്റെ അതേ ഒപ്പ് ഉണ്ട്, അതിലേക്ക് അയച്ച പാരാമീറ്റർ അതേ ഫംഗ്‌ഷൻ ചെയ്യുന്നു.

ThreadPool.QueueUserWorkItem(...);

അത്ര അറിയപ്പെടാത്ത ത്രെഡ് പൂൾ രീതി RegisterWaitForSingleObject നോൺ-ബ്ലോക്കിംഗ് IO ഓപ്പറേഷനുകൾ സംഘടിപ്പിക്കാൻ ഉപയോഗിക്കുന്നു. WaitHandle ഈ രീതിയിലേക്ക് പാസ്സാക്കിയ ഡെലിഗേറ്റിനെ "റിലീസ് ചെയ്തു" എന്ന് വിളിക്കും.

ThreadPool.RegisterWaitForSingleObject(...)

.NET-ന് ഒരു ത്രെഡ് ടൈമർ ഉണ്ട്, അത് WinForms/WPF ടൈമറുകളിൽ നിന്ന് വ്യത്യസ്തമാണ്, പൂളിൽ നിന്ന് എടുത്ത ഒരു ത്രെഡിൽ അതിന്റെ ഹാൻഡ്‌ലർ വിളിക്കപ്പെടും.

System.Threading.Timer

പൂളിൽ നിന്നുള്ള ഒരു ത്രെഡിലേക്ക് നിർവ്വഹണത്തിനായി ഒരു പ്രതിനിധിയെ അയയ്‌ക്കുന്നതിന് തികച്ചും വിചിത്രമായ ഒരു മാർഗമുണ്ട് - BeginInvoke രീതി.

DelegateInstance.BeginInvoke

മേൽപ്പറഞ്ഞ പല രീതികളെയും വിളിക്കാവുന്ന പ്രവർത്തനത്തെക്കുറിച്ച് ഹ്രസ്വമായി സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു - Kernel32.dll Win32 API-ൽ നിന്നുള്ള CreateThread. ഈ ഫംഗ്ഷനെ വിളിക്കാൻ ഒരു വഴിയുണ്ട്, ബാഹ്യ രീതികളുടെ മെക്കാനിസത്തിന് നന്ദി. ലെഗസി കോഡിന്റെ ഭയാനകമായ ഉദാഹരണത്തിൽ ഒരിക്കൽ മാത്രമാണ് ഞാൻ അത്തരമൊരു കോൾ കണ്ടത്, ഇത് കൃത്യമായി ചെയ്ത രചയിതാവിന്റെ പ്രചോദനം ഇപ്പോഴും എനിക്ക് ഒരു രഹസ്യമായി തുടരുന്നു.

Kernel32.dll CreateThread

ത്രെഡുകൾ കാണുകയും ഡീബഗ്ഗുചെയ്യുകയും ചെയ്യുന്നു

നിങ്ങൾ സൃഷ്‌ടിച്ച ത്രെഡുകളും എല്ലാ മൂന്നാം കക്ഷി ഘടകങ്ങളും .NET പൂളും വിഷ്വൽ സ്റ്റുഡിയോയുടെ ത്രെഡ്‌സ് വിൻഡോയിൽ കാണാനാകും. ആപ്ലിക്കേഷൻ ഡീബഗ്ഗിന് കീഴിലും ബ്രേക്ക് മോഡിലും ആയിരിക്കുമ്പോൾ മാത്രമേ ഈ വിൻഡോ ത്രെഡ് വിവരങ്ങൾ പ്രദർശിപ്പിക്കുകയുള്ളൂ. ഇവിടെ നിങ്ങൾക്ക് ഓരോ ത്രെഡിന്റെയും സ്റ്റാക്ക് നാമങ്ങളും മുൻഗണനകളും സൗകര്യപ്രദമായി കാണാനും ഒരു പ്രത്യേക ത്രെഡിലേക്ക് ഡീബഗ്ഗിംഗ് മാറ്റാനും കഴിയും. ത്രെഡ് ക്ലാസിന്റെ മുൻഗണനാ പ്രോപ്പർട്ടി ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഒരു ത്രെഡിന്റെ മുൻഗണന സജ്ജമാക്കാൻ കഴിയും, ത്രെഡുകൾക്കിടയിൽ പ്രൊസസർ സമയം വിഭജിക്കുമ്പോൾ OC, CLR എന്നിവ ഒരു ശുപാർശയായി മനസ്സിലാക്കും.

ടാസ്ക് പാരലൽ ലൈബ്രറി

ടാസ്ക് പാരലൽ ലൈബ്രറി (TPL) .NET 4.0-ൽ അവതരിപ്പിച്ചു. ഇപ്പോൾ ഇത് അസിൻക്രണിയോടൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള സ്റ്റാൻഡേർഡും പ്രധാന ഉപകരണവുമാണ്. പഴയ സമീപനം ഉപയോഗിക്കുന്ന ഏതൊരു കോഡും പാരമ്പര്യമായി കണക്കാക്കപ്പെടുന്നു. System.Threading.Tasks നെയിംസ്‌പേസിൽ നിന്നുള്ള ടാസ്‌ക് ക്ലാസാണ് TPL-ന്റെ അടിസ്ഥാന യൂണിറ്റ്. ഒരു ത്രെഡിന് മുകളിലുള്ള അമൂർത്തീകരണമാണ് ടാസ്ക്. C# ഭാഷയുടെ പുതിയ പതിപ്പ് ഉപയോഗിച്ച്, ടാസ്‌ക്കുകൾക്കൊപ്പം പ്രവർത്തിക്കാനുള്ള ഒരു ഗംഭീരമായ മാർഗം ഞങ്ങൾക്ക് ലഭിച്ചു - async/waiit operators. ഈ ആശയങ്ങൾ അസമന്വിത കോഡ് ലളിതവും സമന്വയമുള്ളതുമായി എഴുതുന്നത് സാധ്യമാക്കി, ഇത് ത്രെഡുകളുടെ ആന്തരിക പ്രവർത്തനങ്ങളെക്കുറിച്ച് കാര്യമായ ധാരണയില്ലാത്ത ആളുകൾക്ക് പോലും അവ ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകൾ എഴുതുന്നത് സാധ്യമാക്കി. async/wait ഉപയോഗിക്കുന്നത് ഒന്നോ അതിലധികമോ ലേഖനങ്ങൾക്കുള്ള ഒരു വിഷയമാണ്, എന്നാൽ അതിന്റെ സാരാംശം കുറച്ച് വാക്യങ്ങളിൽ കണ്ടെത്താൻ ഞാൻ ശ്രമിക്കും:

• async എന്നത് ടാസ്ക് അല്ലെങ്കിൽ ശൂന്യത തിരികെ നൽകുന്ന ഒരു രീതിയുടെ മോഡിഫയറാണ്
• കൂടാതെ await ഒരു നോൺ-ബ്ലോക്കിംഗ് ടാസ്‌ക് വെയിറ്റിംഗ് ഓപ്പറേറ്ററാണ്.

ഒരിക്കൽ കൂടി: വെയിറ്റ് ഓപ്പറേറ്റർ, പൊതുവായ സാഹചര്യത്തിൽ (ഒഴിവാക്കലുകൾ ഉണ്ട്), നിലവിലെ എക്സിക്യൂഷൻ ത്രെഡ് കൂടുതൽ റിലീസ് ചെയ്യും, ടാസ്ക് അതിന്റെ നിർവ്വഹണം പൂർത്തിയാകുമ്പോൾ, ത്രെഡ് (വാസ്തവത്തിൽ, സന്ദർഭം പറയുന്നത് കൂടുതൽ ശരിയായിരിക്കും. , എന്നാൽ പിന്നീട് അതിനെക്കുറിച്ച് കൂടുതൽ) ഈ രീതി കൂടുതൽ നടപ്പിലാക്കുന്നത് തുടരും. .NET-നുള്ളിൽ, ഈ സംവിധാനം വിളവ് റിട്ടേൺ പോലെ തന്നെ നടപ്പിലാക്കുന്നു, എഴുതിയ രീതി ഒരു മുഴുവൻ ക്ലാസായി മാറുമ്പോൾ, ഇത് ഒരു സംസ്ഥാന യന്ത്രമാണ്, ഈ അവസ്ഥകളെ ആശ്രയിച്ച് പ്രത്യേക കഷണങ്ങളായി നടപ്പിലാക്കാൻ കഴിയും. താൽപ്പര്യമുള്ള ആർക്കും കംപൈലർ ജനറേറ്റഡ് കോഡ് പ്രവർത്തനക്ഷമമാക്കി ജെറ്റ് ബ്രെയിൻസ് ഡോട്ട്പീക്ക് ഉപയോഗിച്ച് അസംബ്ലി, അസംബ്ലി/വെയ്റ്റ് ഉപയോഗിച്ച് ഏതെങ്കിലും ലളിതമായ കോഡ് എഴുതാനും കംപൈൽ ചെയ്യാനും കാണാനും കഴിയും.

ഒരു ടാസ്ക് സമാരംഭിക്കുന്നതിനും ഉപയോഗിക്കുന്നതിനുമുള്ള ഓപ്ഷനുകൾ നോക്കാം. ചുവടെയുള്ള കോഡ് ഉദാഹരണത്തിൽ, ഉപയോഗപ്രദമായ ഒന്നും ചെയ്യാത്ത ഒരു പുതിയ ടാസ്‌ക് ഞങ്ങൾ സൃഷ്‌ടിക്കുന്നു (ത്രെഡ്.സ്ലീപ്പ്(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
}

നിരവധി ഓപ്ഷനുകൾ ഉപയോഗിച്ച് ഒരു ടാസ്ക് സൃഷ്ടിക്കപ്പെടുന്നു:

• ടാസ്‌ക് വേഗത്തിൽ പൂർത്തിയാകില്ല എന്നതിന്റെ സൂചനയാണ് ലോംഗ് റണ്ണിംഗ്, അതിനർത്ഥം പൂളിൽ നിന്ന് ഒരു ത്രെഡ് എടുക്കാതെ, മറ്റുള്ളവരെ ഉപദ്രവിക്കാതിരിക്കാൻ ഈ ടാസ്‌ക്കിനായി പ്രത്യേകം സൃഷ്‌ടിക്കുന്നത് പരിഗണിക്കുന്നത് മൂല്യവത്താണ്.
• AttachedToParent - ചുമതലകൾ ഒരു ശ്രേണിയിൽ ക്രമീകരിക്കാം. ഈ ഓപ്‌ഷൻ ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ, ടാസ്‌ക് അത് തന്നെ പൂർത്തിയാക്കി കുട്ടികളുടെ നിർവ്വഹണത്തിനായി കാത്തിരിക്കുന്ന അവസ്ഥയിലായിരിക്കാം.
• പ്രിഫർഫെയർനെസ് - നിർവ്വഹണത്തിനായി അയച്ച ടാസ്‌ക്കുകൾ പിന്നീട് അയയ്‌ക്കുന്നതിന് മുമ്പ് എക്‌സിക്യൂട്ട് ചെയ്യുന്നതാണ് നല്ലത് എന്നാണ് അർത്ഥമാക്കുന്നത്. എന്നാൽ ഇത് ഒരു ശുപാർശ മാത്രമാണ്, ഫലങ്ങൾ ഉറപ്പുനൽകുന്നില്ല.

രീതിയിലേക്ക് കൈമാറിയ രണ്ടാമത്തെ പാരാമീറ്റർ CancellationToken ആണ്. ഒരു ഓപ്പറേഷൻ ആരംഭിച്ചതിന് ശേഷം അത് റദ്ദാക്കുന്നത് ശരിയായി കൈകാര്യം ചെയ്യാൻ, എക്സിക്യൂട്ട് ചെയ്യുന്ന കോഡ് CancellationToken നിലയ്ക്കുള്ള ചെക്കുകൾ കൊണ്ട് പൂരിപ്പിക്കണം. പരിശോധനകളൊന്നും ഇല്ലെങ്കിൽ, CancellationTokenSource ഒബ്‌ജക്‌റ്റിൽ വിളിക്കുന്ന റദ്ദാക്കൽ രീതിക്ക് ടാസ്‌ക് ആരംഭിക്കുന്നതിന് മുമ്പ് മാത്രമേ അതിന്റെ നിർവ്വഹണം നിർത്താൻ കഴിയൂ.

ടാസ്ക് ഷെഡ്യൂളർ എന്ന തരത്തിന്റെ ഷെഡ്യൂളർ ഒബ്ജക്റ്റാണ് അവസാന പാരാമീറ്റർ. ത്രെഡുകളിലുടനീളം ടാസ്‌ക്കുകൾ വിതരണം ചെയ്യുന്നതിനുള്ള തന്ത്രങ്ങൾ നിയന്ത്രിക്കുന്നതിനാണ് ഈ ക്ലാസും അതിന്റെ പിൻഗാമികളും രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത്; സ്ഥിരസ്ഥിതിയായി, പൂളിൽ നിന്നുള്ള ഒരു റാൻഡം ത്രെഡിൽ ടാസ്‌ക് എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടും.

വെയിറ്റ് ഓപ്പറേറ്റർ സൃഷ്‌ടിച്ച ടാസ്‌ക്കിലേക്ക് പ്രയോഗിക്കുന്നു, അതിനർത്ഥം അതിന് ശേഷം എഴുതിയ കോഡ്, ഒന്ന് ഉണ്ടെങ്കിൽ, കാത്തിരിക്കുന്നതിന് മുമ്പുള്ള കോഡിന്റെ അതേ സന്ദർഭത്തിൽ (പലപ്പോഴും ഇത് ഒരേ ത്രെഡിൽ) എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടും.

ഈ രീതി അസിൻക് ശൂന്യമായി അടയാളപ്പെടുത്തിയിരിക്കുന്നു, അതിനർത്ഥം ഇതിന് വെയിറ്റ് ഓപ്പറേറ്റർ ഉപയോഗിക്കാമെന്നാണ്, എന്നാൽ കോളിംഗ് കോഡിന് നിർവ്വഹണത്തിനായി കാത്തിരിക്കാനാവില്ല. അത്തരമൊരു സവിശേഷത ആവശ്യമാണെങ്കിൽ, രീതി ടാസ്ക് തിരികെ നൽകണം. അസിൻക് ശൂന്യമായി അടയാളപ്പെടുത്തിയ രീതികൾ വളരെ സാധാരണമാണ്: ചട്ടം പോലെ, ഇവ ഇവന്റ് ഹാൻഡ്‌ലറുകൾ അല്ലെങ്കിൽ തീയിൽ പ്രവർത്തിക്കുന്ന മറ്റ് രീതികളാണ്, തത്വം മറക്കുക. നിർവ്വഹണത്തിന്റെ അവസാനം വരെ കാത്തിരിക്കാൻ നിങ്ങൾക്ക് അവസരം നൽകേണ്ടതല്ല, ഫലം തിരികെ നൽകേണ്ടതുണ്ടെങ്കിൽ, നിങ്ങൾ ടാസ്ക് ഉപയോഗിക്കേണ്ടതുണ്ട്.

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/waiit ഉപയോഗിക്കുമ്പോൾ അസിൻക്രണസ് കോഡിലെ പിശകുകൾ കൈകാര്യം ചെയ്യാൻ വളരെ എളുപ്പമാണ് എന്നതാണ് വസ്തുത - കോഡ് സിൻക്രണസ് ആണെങ്കിൽ അവ സമാനമാണ്. ഞങ്ങൾ ഒരു ടാസ്‌ക്കിൽ സിൻക്രണസ് വെയിറ്റ് എക്‌സോർസിസം പ്രയോഗിക്കുകയാണെങ്കിൽ, യഥാർത്ഥ ഒഴിവാക്കൽ ഒരു അഗ്രഗേറ്റ് എക്‌സെപ്‌ഷനായി മാറുന്നു, അതായത്. അപവാദം കൈകാര്യം ചെയ്യാൻ, നിങ്ങൾ InnerException തരം പരിശോധിച്ച് ഒരു ക്യാച്ച് ബ്ലോക്കിനുള്ളിൽ സ്വയം ഒരു if ചെയിൻ എഴുതണം അല്ലെങ്കിൽ C# ലോകത്ത് കൂടുതൽ പരിചിതമായ ക്യാച്ച് ബ്ലോക്കുകളുടെ ശൃംഖലയ്ക്ക് പകരം നിർമ്മിക്കുമ്പോൾ ക്യാച്ച് ഉപയോഗിക്കുക.

മൂന്നാമത്തേതും അവസാനത്തേതുമായ ഉദാഹരണങ്ങളും ഇതേ കാരണത്താൽ മോശമായി അടയാളപ്പെടുത്തുകയും ഒരേ പ്രശ്‌നങ്ങൾ ഉൾക്കൊള്ളുകയും ചെയ്യുന്നു.

ഒരു കൂട്ടം ടാസ്‌ക്കുകൾക്കായി കാത്തിരിക്കുന്നതിന് എപ്പോൾ എനി, എപ്പോൾ എല്ലാം രീതികൾ വളരെ സൗകര്യപ്രദമാണ്; അവ ഒരു കൂട്ടം ടാസ്‌ക്കുകൾ ഒന്നായി പൊതിയുന്നു, ഒന്നുകിൽ ഗ്രൂപ്പിൽ നിന്നുള്ള ഒരു ടാസ്‌ക് ആദ്യം പ്രവർത്തനക്ഷമമാകുമ്പോഴോ അല്ലെങ്കിൽ അവയെല്ലാം അവയുടെ നിർവ്വഹണം പൂർത്തിയാകുമ്പോഴോ അത് ഫയർ ചെയ്യും.

ത്രെഡുകൾ നിർത്തുന്നു

വിവിധ കാരണങ്ങളാൽ, അത് ആരംഭിച്ചതിന് ശേഷം ഒഴുക്ക് നിർത്തേണ്ടത് ആവശ്യമായി വന്നേക്കാം. ഇത് ചെയ്യുന്നതിന് നിരവധി മാർഗങ്ങളുണ്ട്. ത്രെഡ് ക്ലാസിന് ഉചിതമായി പേരിട്ടിരിക്കുന്ന രണ്ട് രീതികളുണ്ട്: ഉപേക്ഷിക്കുക и ഇന്ററപ്റ്റ്. ആദ്യത്തേത് ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നില്ല, കാരണം ഏതെങ്കിലും ക്രമരഹിത നിമിഷത്തിൽ വിളിച്ചതിന് ശേഷം, ഏതെങ്കിലും നിർദ്ദേശത്തിന്റെ പ്രോസസ്സിംഗ് സമയത്ത്, ഒരു അപവാദം എറിയപ്പെടും ThreadAbortedException. ഏതെങ്കിലും പൂർണ്ണസംഖ്യ വേരിയബിൾ വർദ്ധിപ്പിക്കുമ്പോൾ അത്തരമൊരു ഒഴിവാക്കൽ നിങ്ങൾ പ്രതീക്ഷിക്കുന്നില്ല, അല്ലേ? ഈ രീതി ഉപയോഗിക്കുമ്പോൾ, ഇത് വളരെ യഥാർത്ഥ സാഹചര്യമാണ്. കോഡിന്റെ ഒരു പ്രത്യേക വിഭാഗത്തിൽ അത്തരം ഒരു അപവാദം സൃഷ്ടിക്കുന്നതിൽ നിന്ന് നിങ്ങൾക്ക് CLR-നെ തടയണമെങ്കിൽ, നിങ്ങൾക്ക് അത് കോളുകളിൽ പൊതിയാവുന്നതാണ്. Thread.BeginCriticalRegion, ത്രെഡ്.എൻഡ് ക്രിട്ടിക്കൽ റീജിയൻ. അവസാന ബ്ലോക്കിൽ എഴുതിയ ഏത് കോഡും അത്തരം കോളുകളിൽ പൊതിഞ്ഞതാണ്. ഇക്കാരണത്താൽ, ഫ്രെയിംവർക്ക് കോഡിന്റെ ആഴത്തിൽ നിങ്ങൾക്ക് ഒരു ശൂന്യമായ ശ്രമത്തിലൂടെ ബ്ലോക്കുകൾ കണ്ടെത്താനാകും, പക്ഷേ ഒടുവിൽ ശൂന്യമല്ല. മൈക്രോസോഫ്റ്റ് ഈ രീതി നിരുത്സാഹപ്പെടുത്തുന്നു, അവർ ഇത് .net core-ൽ ഉൾപ്പെടുത്തിയില്ല.

ഇന്ററപ്റ്റ് രീതി കൂടുതൽ പ്രവചനാതീതമായി പ്രവർത്തിക്കുന്നു. ഇതിന് ഒരു അപവാദം ഉപയോഗിച്ച് ത്രെഡിനെ തടസ്സപ്പെടുത്താം ThreadInterruptedException ത്രെഡ് കാത്തിരിക്കുന്ന അവസ്ഥയിലായിരിക്കുമ്പോൾ മാത്രം. WaitHandle, ലോക്ക്, അല്ലെങ്കിൽ Thread.Sleep എന്ന് വിളിച്ചതിന് ശേഷം തൂങ്ങിക്കിടക്കുമ്പോൾ ഇത് ഈ അവസ്ഥയിലേക്ക് പ്രവേശിക്കുന്നു.

മുകളിൽ വിവരിച്ച രണ്ട് ഓപ്ഷനുകളും അവയുടെ പ്രവചനാതീതമായതിനാൽ മോശമാണ്. ഒരു ഘടന ഉപയോഗിക്കുക എന്നതാണ് പരിഹാരം റദ്ദാക്കൽ ടോക്കൺ ക്ലാസും CancellationTokenSource. കാര്യം ഇതാണ്: CancellationTokenSource ക്ലാസിന്റെ ഒരു ഉദാഹരണം സൃഷ്‌ടിക്കപ്പെട്ടു, അതിന്റെ ഉടമയ്‌ക്ക് മാത്രമേ രീതി വിളിച്ച് പ്രവർത്തനം നിർത്താൻ കഴിയൂ. റദ്ദാക്കുക. ക്യാൻസലേഷൻ ടോക്കൺ മാത്രമേ ഓപ്പറേഷനിലേക്ക് കൈമാറുകയുള്ളൂ. CancellationToken ഉടമകൾക്ക് സ്വയം പ്രവർത്തനം റദ്ദാക്കാൻ കഴിയില്ല, എന്നാൽ പ്രവർത്തനം റദ്ദാക്കിയിട്ടുണ്ടോ എന്ന് മാത്രമേ പരിശോധിക്കാൻ കഴിയൂ. ഇതിനായി ഒരു ബൂളിയൻ പ്രോപ്പർട്ടി ഉണ്ട് റദ്ദാക്കൽ അഭ്യർത്ഥിച്ചു രീതിയും ത്രോIfCancelRequested. രണ്ടാമത്തേത് ഒരു അപവാദം എറിയും TaskCancelledException CancellationToken ഉദാഹരണം തത്തയായി കാണുമ്പോൾ റദ്ദാക്കൽ രീതി വിളിച്ചിരുന്നുവെങ്കിൽ. ഞാൻ ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്ന രീതി ഇതാണ്. ഏത് സമയത്താണ് ഒരു അപവാദ പ്രവർത്തനം നിർത്തലാക്കാൻ കഴിയുക എന്നതിന്റെ പൂർണ്ണ നിയന്ത്രണം നേടുന്നതിലൂടെ ഇത് മുമ്പത്തെ ഓപ്ഷനുകളെ അപേക്ഷിച്ച് ഒരു മെച്ചപ്പെടുത്തലാണ്.

ഒരു ത്രെഡ് നിർത്തുന്നതിനുള്ള ഏറ്റവും ക്രൂരമായ ഓപ്ഷൻ Win32 API ടെർമിനേറ്റ് ത്രെഡ് ഫംഗ്‌ഷനെ വിളിക്കുക എന്നതാണ്. ഈ ഫംഗ്‌ഷൻ വിളിച്ചതിന് ശേഷമുള്ള CLR-ന്റെ പെരുമാറ്റം പ്രവചനാതീതമായിരിക്കാം. MSDN-ൽ ഈ ഫംഗ്‌ഷനെക്കുറിച്ച് ഇനിപ്പറയുന്നവ എഴുതിയിരിക്കുന്നു: “ടെർമിനേറ്റ് ത്രെഡ് അപകടകരമായ ഒരു ഫംഗ്‌ഷനാണ്, അത് അങ്ങേയറ്റത്തെ സന്ദർഭങ്ങളിൽ മാത്രം ഉപയോഗിക്കേണ്ടതാണ്. "

FromAsync രീതി ഉപയോഗിച്ച് ലെഗസി API ടാസ്‌ക് ബേസ്ഡ് ആയി പരിവർത്തനം ചെയ്യുന്നു

ടാസ്‌ക്കുകൾ അവതരിപ്പിച്ചതിന് ശേഷം ആരംഭിച്ച ഒരു പ്രോജക്‌റ്റിൽ പ്രവർത്തിക്കാൻ നിങ്ങൾക്ക് ഭാഗ്യമുണ്ടെങ്കിൽ, മിക്ക ഡെവലപ്പർമാരെയും നിശബ്ദമായി ഭയപ്പെടുത്തുന്നത് അവസാനിപ്പിച്ചാൽ, നിങ്ങൾക്ക് ധാരാളം പഴയ API-കൾ, മൂന്നാം കക്ഷികൾ, നിങ്ങളുടെ ടീം എന്നിവയുമായി ഇടപെടേണ്ടി വരില്ല. പണ്ട് പീഡിപ്പിച്ചിട്ടുണ്ട്. ഭാഗ്യവശാൽ, .NET ഫ്രെയിംവർക്ക് ടീം ഞങ്ങളുടെ സംരക്ഷണം ഏറ്റെടുത്തു, ഒരുപക്ഷെ ലക്ഷ്യം നമ്മളെത്തന്നെ പരിപാലിക്കുക എന്നതായിരിക്കാം. അതെന്തായാലും, പഴയ അസിൻക്രണസ് പ്രോഗ്രാമിംഗ് സമീപനങ്ങളിൽ എഴുതിയിരിക്കുന്ന കോഡ് പുതിയതിലേക്ക് വേദനയില്ലാതെ പരിവർത്തനം ചെയ്യുന്നതിനുള്ള നിരവധി ടൂളുകൾ .NET-നുണ്ട്. അവയിലൊന്നാണ് ടാസ്‌ക്ഫാക്‌ടറിയുടെ ഫ്രംഅസിങ്ക് രീതി. ചുവടെയുള്ള കോഡ് ഉദാഹരണത്തിൽ, ഈ രീതി ഉപയോഗിച്ച് ഒരു ടാസ്‌ക്കിൽ WebRequest ക്ലാസിന്റെ പഴയ അസിൻക് രീതികൾ ഞാൻ പൊതിയുന്നു.

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

ഇതൊരു ഉദാഹരണം മാത്രമാണ്, ബിൽറ്റ്-ഇൻ തരങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾ ഇത് ചെയ്യാൻ സാധ്യതയില്ല, എന്നാൽ ഏത് പഴയ പ്രോജക്‌റ്റും അത് സ്വീകരിക്കുന്ന IAsyncResult, EndDoSomething രീതികൾ നൽകുന്ന BeginDoSomething രീതികളാൽ നിറഞ്ഞിരിക്കുന്നു.

TaskCompletionSource ക്ലാസ് ഉപയോഗിച്ച് ലെഗസി API-ലേക്ക് ടാസ്‌ക് ബേസ്ഡ് ആയി പരിവർത്തനം ചെയ്യുക

പരിഗണിക്കേണ്ട മറ്റൊരു പ്രധാന ഉപകരണം ക്ലാസ് ആണ് TaskCompletionSource. പ്രവർത്തനങ്ങൾ, ഉദ്ദേശ്യം, പ്രവർത്തന തത്വം എന്നിവയുടെ കാര്യത്തിൽ, ഇത് ഞാൻ മുകളിൽ എഴുതിയ ThreadPool ക്ലാസിന്റെ RegisterWaitForSingleObject രീതിയെ ഒരു പരിധിവരെ അനുസ്മരിപ്പിക്കുന്നതായിരിക്കാം. ഈ ക്ലാസ് ഉപയോഗിച്ച്, ടാസ്‌ക്കുകളിൽ പഴയ അസിൻക്രണസ് എപിഐകൾ നിങ്ങൾക്ക് എളുപ്പത്തിലും സൗകര്യപ്രദമായും പൊതിയാനാകും.

ഈ ആവശ്യങ്ങൾക്കായി ഉദ്ദേശിച്ചിട്ടുള്ള TaskFactory ക്ലാസ്സിന്റെ FromAsync രീതിയെക്കുറിച്ച് ഞാൻ ഇതിനകം സംസാരിച്ചുവെന്ന് നിങ്ങൾ പറയും. കഴിഞ്ഞ 15 വർഷമായി മൈക്രോസോഫ്റ്റ് വാഗ്ദാനം ചെയ്ത .net-ലെ അസിൻക്രണസ് മോഡലുകളുടെ വികസനത്തിന്റെ മുഴുവൻ ചരിത്രവും ഇവിടെ നാം ഓർക്കേണ്ടതുണ്ട്: ടാസ്ക്-ബേസ്ഡ് അസിൻക്രണസ് പാറ്റേണിന് (ടിഎപി) മുമ്പ്, എസിൻക്രണസ് പ്രോഗ്രാമിംഗ് പാറ്റേൺ (എപിപി) ഉണ്ടായിരുന്നു. രീതികളെ കുറിച്ചായിരുന്നു ആരംഭിക്കുന്നുഎന്തെങ്കിലും തിരിച്ചുവരുന്നു IAsyncResult രീതികളും അവസാനിക്കുന്നുDoSomething അത് അംഗീകരിക്കുകയും ഈ വർഷത്തെ പൈതൃകത്തിന് FromAsync രീതി തികഞ്ഞതാണ്, എന്നാൽ കാലക്രമേണ, അത് ഇവന്റ് ബേസ്ഡ് അസിൻക്രണസ് പാറ്റേൺ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചു (EAP), അസിൻക്രണസ് പ്രവർത്തനം പൂർത്തിയാകുമ്പോൾ ഒരു ഇവന്റ് ഉയർന്നുവരുമെന്ന് അനുമാനിച്ചു.

ഇവന്റ് മോഡലിന് ചുറ്റും നിർമ്മിച്ച ടാസ്‌ക്കുകളും ലെഗസി API-കളും പൊതിയുന്നതിന് TaskCompletionSource അനുയോജ്യമാണ്. അതിന്റെ പ്രവർത്തനത്തിന്റെ സാരാംശം ഇപ്രകാരമാണ്: ഈ ക്ലാസിന്റെ ഒരു വസ്തുവിന് ടാസ്‌ക് എന്ന തരത്തിലുള്ള ഒരു പൊതു സ്വത്ത് ഉണ്ട്, അതിന്റെ അവസ്ഥ TaskCompletionSource ക്ലാസിന്റെ SetResult, SetException മുതലായവ വഴി നിയന്ത്രിക്കാനാകും. ഈ ടാസ്‌ക്കിൽ വെയിറ്റ് ഓപ്പറേറ്റർ പ്രയോഗിച്ച സ്ഥലങ്ങളിൽ, ടാസ്‌ക് കോംപ്ലിഷൻ സോഴ്‌സിൽ പ്രയോഗിച്ച രീതിയെ ആശ്രയിച്ച് ഇത് എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടും അല്ലെങ്കിൽ പരാജയപ്പെടും. ഇത് ഇപ്പോഴും വ്യക്തമല്ലെങ്കിൽ, ഈ കോഡ് ഉദാഹരണം നോക്കാം, ചില പഴയ EAP API ഒരു 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 നുറുങ്ങുകളും തന്ത്രങ്ങളും

TaskCompletionSource ഉപയോഗിച്ച് പഴയ APIകൾ പൊതിയുക മാത്രമല്ല ചെയ്യുന്നത്. ഈ ക്ലാസ് ഉപയോഗിക്കുന്നത്, ത്രെഡുകൾ ഉൾക്കൊള്ളാത്ത ടാസ്‌ക്കുകളിൽ വിവിധ API-കൾ രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള രസകരമായ ഒരു സാധ്യത തുറക്കുന്നു. സ്ട്രീം, ഞങ്ങൾ ഓർക്കുന്നതുപോലെ, വിലയേറിയ ഒരു വിഭവമാണ്, അവയുടെ എണ്ണം പരിമിതമാണ് (പ്രധാനമായും റാമിന്റെ അളവിൽ). സങ്കീർണ്ണമായ ബിസിനസ്സ് ലോജിക്കോടുകൂടിയ ഒരു ലോഡ് ചെയ്ത വെബ് ആപ്ലിക്കേഷൻ വികസിപ്പിക്കുന്നതിലൂടെ ഈ പരിമിതി എളുപ്പത്തിൽ നേടാനാകും. ലോംഗ്-പോളിംഗ് പോലുള്ള ഒരു ട്രിക്ക് നടപ്പിലാക്കുമ്പോൾ ഞാൻ സംസാരിക്കുന്ന സാധ്യതകൾ പരിഗണിക്കാം.

ചുരുക്കത്തിൽ, തന്ത്രത്തിന്റെ സാരാംശം ഇതാണ്: API-ൽ നിന്ന് അതിന്റെ ഭാഗത്ത് സംഭവിക്കുന്ന ചില സംഭവങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് വിവരങ്ങൾ ലഭിക്കേണ്ടതുണ്ട്, അതേസമയം API-ക്ക് ചില കാരണങ്ങളാൽ ഇവന്റ് റിപ്പോർട്ട് ചെയ്യാൻ കഴിയില്ല, പക്ഷേ സംസ്ഥാനം മാത്രമേ തിരികെ നൽകാനാകൂ. വെബ്‌സോക്കറ്റിന് മുമ്പോ അല്ലെങ്കിൽ ചില കാരണങ്ങളാൽ ഈ സാങ്കേതികവിദ്യ ഉപയോഗിക്കുന്നത് അസാധ്യമായപ്പോഴോ HTTP-യുടെ മുകളിൽ നിർമ്മിച്ച എല്ലാ API-കളും ഇവയുടെ ഒരു ഉദാഹരണമാണ്. ക്ലയന്റിന് HTTP സെർവറിനോട് ചോദിക്കാൻ കഴിയും. HTTP സെർവറിന് ക്ലയന്റുമായി ആശയവിനിമയം ആരംഭിക്കാൻ കഴിയില്ല. ഒരു ടൈമർ ഉപയോഗിച്ച് സെർവറിൽ വോട്ടെടുപ്പ് നടത്തുക എന്നതാണ് ഒരു ലളിതമായ പരിഹാരം, എന്നാൽ ഇത് സെർവറിൽ അധിക ലോഡും ശരാശരി ടൈമർഇന്റർവെൽ / 2-ൽ അധിക കാലതാമസവും സൃഷ്ടിക്കുന്നു. ഇത് മറികടക്കാൻ, ലോംഗ് പോളിംഗ് എന്ന ഒരു ട്രിക്ക് കണ്ടുപിടിച്ചു, അതിൽ നിന്നുള്ള പ്രതികരണം വൈകുന്നത് ഉൾപ്പെടുന്നു. സമയപരിധി അവസാനിക്കുന്നതുവരെ അല്ലെങ്കിൽ ഒരു ഇവന്റ് സംഭവിക്കുന്നത് വരെ സെർവർ. ഇവന്റ് സംഭവിച്ചിട്ടുണ്ടെങ്കിൽ, അത് പ്രോസസ്സ് ചെയ്യുന്നു, ഇല്ലെങ്കിൽ, അഭ്യർത്ഥന വീണ്ടും അയയ്ക്കും.

while(!eventOccures && !timeoutExceeded)  {

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

എന്നാൽ ഇവന്റിനായി കാത്തിരിക്കുന്ന ക്ലയന്റുകളുടെ എണ്ണം വർദ്ധിക്കുന്നതോടെ അത്തരമൊരു പരിഹാരം ഭയാനകമാണെന്ന് തെളിയിക്കും, കാരണം... അത്തരം ഓരോ ക്ലയന്റും ഒരു ഇവന്റിനായി കാത്തിരിക്കുന്ന ഒരു മുഴുവൻ ത്രെഡും ഉൾക്കൊള്ളുന്നു. അതെ, ഇവന്റ് പ്രവർത്തനക്ഷമമാകുമ്പോൾ ഞങ്ങൾക്ക് അധികമായി 1മി.സ് കാലതാമസം ലഭിക്കുന്നു, മിക്കപ്പോഴും ഇത് പ്രാധാന്യമർഹിക്കുന്നതല്ല, പക്ഷേ സോഫ്‌റ്റ്‌വെയറിനെ അതിനെക്കാൾ മോശമാക്കുന്നത് എന്തുകൊണ്ട്? ഞങ്ങൾ 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 സൃഷ്ടിക്കുകയും സ്ഥാപിക്കുകയും ചെയ്യുന്നു, തുടർന്ന് ആദ്യം എന്താണ് സംഭവിക്കുന്നതെന്ന് കാത്തിരിക്കുക: നിർദ്ദിഷ്ട സമയ ഇടവേള കാലഹരണപ്പെടും അല്ലെങ്കിൽ ഒരു സന്ദേശം ലഭിക്കും.

മൂല്യ ടാസ്ക്: എന്തുകൊണ്ട്, എങ്ങനെ

യീൽഡ് റിട്ടേൺ ഓപ്പറേറ്റർ പോലെയുള്ള അസിൻക്/വെയ്റ്റ് ഓപ്പറേറ്റർമാർ, ഈ രീതിയിൽ നിന്ന് ഒരു സ്റ്റേറ്റ് മെഷീൻ സൃഷ്ടിക്കുന്നു, ഇത് ഒരു പുതിയ ഒബ്‌ജക്റ്റിന്റെ സൃഷ്‌ടിയാണ്, ഇത് മിക്കവാറും എല്ലായ്‌പ്പോഴും പ്രധാനമല്ല, എന്നാൽ അപൂർവ സന്ദർഭങ്ങളിൽ ഇത് ഒരു പ്രശ്‌നം സൃഷ്‌ടിച്ചേക്കാം. ഈ കേസ് ശരിക്കും പലപ്പോഴും വിളിക്കപ്പെടുന്ന ഒരു രീതിയായിരിക്കാം, നമ്മൾ സംസാരിക്കുന്നത് സെക്കൻഡിൽ പതിനായിരക്കണക്കിന് കോളുകളെക്കുറിച്ചാണ്. അത്തരം ഒരു രീതി മിക്ക കേസുകളിലും എല്ലാ കാത്തിരിക്കുന്ന രീതികളെയും മറികടന്ന് ഫലം നൽകുന്ന തരത്തിലാണ് എഴുതിയതെങ്കിൽ, .NET ഇത് ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനുള്ള ഒരു ടൂൾ നൽകുന്നു - ValueTask ഘടന. ഇത് വ്യക്തമാക്കുന്നതിന്, അതിന്റെ ഉപയോഗത്തിന്റെ ഒരു ഉദാഹരണം നോക്കാം: നമ്മൾ പലപ്പോഴും പോകുന്ന ഒരു കാഷെ ഉണ്ട്. അതിൽ ചില മൂല്യങ്ങളുണ്ട്, തുടർന്ന് ഞങ്ങൾ അവ തിരികെ നൽകും; ഇല്ലെങ്കിൽ, അവ ലഭിക്കുന്നതിന് ഞങ്ങൾ കുറച്ച് സ്ലോ ഐഒയിലേക്ക് പോകുന്നു. രണ്ടാമത്തേത് അസമന്വിതമായി ചെയ്യാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, അതായത് മുഴുവൻ രീതിയും അസമന്വിതമായി മാറുന്നു. അതിനാൽ, രീതി എഴുതുന്നതിനുള്ള വ്യക്തമായ മാർഗ്ഗം ഇപ്രകാരമാണ്:

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

വാസ്തവത്തിൽ, ഈ കേസിലെ ഒപ്റ്റിമൽ പരിഹാരം ഹോട്ട്-പാത്ത് ഒപ്റ്റിമൈസ് ചെയ്യുക എന്നതാണ്, അതായത്, അനാവശ്യമായ അലോക്കേഷനുകളില്ലാതെ നിഘണ്ടുവിൽ നിന്ന് ഒരു മൂല്യം നേടുകയും ജിസിയിൽ ലോഡുചെയ്യുകയും ചെയ്യുക, അത്തരം അപൂർവ സന്ദർഭങ്ങളിൽ ഡാറ്റയ്ക്കായി ഐഒയിലേക്ക് പോകേണ്ടിവരുമ്പോൾ. , എല്ലാം പഴയ രീതിയിൽ പ്ലസ് / മൈനസ് ആയി തുടരും:

public ValueTask<string> GetById(int id) {

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

ഈ കോഡിലേക്ക് നമുക്ക് സൂക്ഷ്മമായി നോക്കാം: കാഷെയിൽ ഒരു മൂല്യമുണ്ടെങ്കിൽ, ഞങ്ങൾ ഒരു ഘടന സൃഷ്ടിക്കുന്നു, അല്ലാത്തപക്ഷം യഥാർത്ഥ ചുമതല അർത്ഥവത്തായ ഒന്നിൽ പൊതിഞ്ഞതായിരിക്കും. ഈ കോഡ് ഏത് പാതയിലാണ് എക്സിക്യൂട്ട് ചെയ്തതെന്ന് കോളിംഗ് കോഡ് ശ്രദ്ധിക്കുന്നില്ല: C# വാക്യഘടനയുടെ വീക്ഷണകോണിൽ നിന്ന് ValueTask, ഈ സാഹചര്യത്തിൽ ഒരു സാധാരണ ടാസ്‌ക്ക് പോലെ തന്നെ പ്രവർത്തിക്കും.

ടാസ്‌ക് ഷെഡ്യൂളർമാർ: ടാസ്‌ക് ലോഞ്ച് സ്ട്രാറ്റജികൾ കൈകാര്യം ചെയ്യുന്നു

ഞാൻ പരിഗണിക്കാൻ ആഗ്രഹിക്കുന്ന അടുത്ത API ക്ലാസ് ആണ് ടാസ്ക് ഷെഡ്യൂളർ അതിന്റെ ഡെറിവേറ്റീവുകളും. ത്രെഡുകളിലുടനീളം ടാസ്‌ക്കുകൾ വിതരണം ചെയ്യുന്നതിനുള്ള തന്ത്രങ്ങൾ കൈകാര്യം ചെയ്യാനുള്ള കഴിവ് TPL-ന് ഉണ്ടെന്ന് ഞാൻ മുകളിൽ സൂചിപ്പിച്ചു. ടാസ്ക് ഷെഡ്യൂളർ ക്ലാസിന്റെ പിൻഗാമികളിൽ ഇത്തരം തന്ത്രങ്ങൾ നിർവചിച്ചിരിക്കുന്നു. നിങ്ങൾക്ക് ആവശ്യമായേക്കാവുന്ന ഏതൊരു തന്ത്രവും ലൈബ്രറിയിൽ കണ്ടെത്താനാകും. സമാന്തര വിപുലീകരണങ്ങൾ, മൈക്രോസോഫ്റ്റ് വികസിപ്പിച്ചെടുത്തത്, എന്നാൽ .NET-ന്റെ ഭാഗമല്ല, മറിച്ച് ഒരു ന്യൂജെറ്റ് പാക്കേജായി വിതരണം ചെയ്യുന്നു. അവയിൽ ചിലത് നമുക്ക് ഹ്രസ്വമായി നോക്കാം:

• CurrentThreadTaskScheduler — നിലവിലെ ത്രെഡിൽ ടാസ്‌ക്കുകൾ നിർവ്വഹിക്കുന്നു
• ലിമിറ്റഡ് കൺകറൻസി ലെവൽ ടാസ്ക് ഷെഡ്യൂളർ - കൺസ്‌ട്രക്‌ടറിൽ അംഗീകരിക്കപ്പെട്ട N പരാമീറ്റർ ഉപയോഗിച്ച് ഒരേസമയം നിർവ്വഹിക്കുന്ന ടാസ്‌ക്കുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നു.
• ഓർഡർ ചെയ്ത ടാസ്ക് ഷെഡ്യൂളർ — LimitedConcurrencyLevelTaskScheduler(1) ആയി നിർവചിച്ചിരിക്കുന്നു, അതിനാൽ ചുമതലകൾ തുടർച്ചയായി നടപ്പിലാക്കും.
• WorkStealingTaskScheduler - നടപ്പിലാക്കുന്നു ജോലി-മോഷ്ടിക്കൽ ചുമതല വിതരണത്തിലേക്കുള്ള സമീപനം. അടിസ്ഥാനപരമായി ഇത് ഒരു പ്രത്യേക ThreadPool ആണ്. .NET ThreadPool-ൽ എല്ലാ ആപ്ലിക്കേഷനുകൾക്കുമുള്ള ഒരു സ്റ്റാറ്റിക് ക്ലാസ് ആണ് എന്ന പ്രശ്നം പരിഹരിക്കുന്നു, അതായത് പ്രോഗ്രാമിന്റെ ഒരു ഭാഗത്ത് അതിന്റെ ഓവർലോഡ് അല്ലെങ്കിൽ തെറ്റായ ഉപയോഗം മറ്റൊന്നിൽ പാർശ്വഫലങ്ങളിലേക്ക് നയിച്ചേക്കാം. മാത്രമല്ല, അത്തരം വൈകല്യങ്ങളുടെ കാരണം മനസ്സിലാക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്. അത്. ത്രെഡ്‌പൂളിന്റെ ഉപയോഗം ആക്രമണാത്മകവും പ്രവചനാതീതവുമാകാനിടയുള്ള പ്രോഗ്രാമിന്റെ ഭാഗങ്ങളിൽ പ്രത്യേക വർക്ക്‌സ്റ്റീലിംഗ് ടാസ്‌ക് ഷെഡ്യൂളറുകൾ ഉപയോഗിക്കേണ്ട ആവശ്യമുണ്ടാകാം.
• ക്യൂഡ് ടാസ്ക് ഷെഡ്യൂളർ — മുൻഗണനാ ക്യൂ നിയമങ്ങൾക്കനുസൃതമായി ചുമതലകൾ നിർവഹിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു
• ThreadPerTaskScheduler — ഓരോ ടാസ്ക്കിനും ഒരു പ്രത്യേക ത്രെഡ് സൃഷ്ടിക്കുന്നു, അത് അതിൽ നടപ്പിലാക്കുന്നു. പ്രവചനാതീതമായ സമയമെടുക്കുന്ന ജോലികൾക്ക് ഇത് ഉപയോഗപ്രദമാകും.

നല്ല വിശദമായി ഉണ്ട് ഒരു ലേഖനം മൈക്രോസോഫ്റ്റ് ബ്ലോഗിലെ ടാസ്ക് ഷെഡ്യൂളറുകളെ കുറിച്ച്.

ടാസ്‌ക്കുകളുമായി ബന്ധപ്പെട്ട എല്ലാറ്റിന്റെയും സൗകര്യപ്രദമായ ഡീബഗ്ഗിംഗിനായി, വിഷ്വൽ സ്റ്റുഡിയോയിൽ ഒരു ടാസ്‌ക് വിൻഡോ ഉണ്ട്. ഈ വിൻഡോയിൽ നിങ്ങൾക്ക് ടാസ്‌ക്കിന്റെ നിലവിലെ അവസ്ഥ കാണാനും നിലവിൽ നടപ്പിലാക്കുന്ന കോഡിന്റെ വരിയിലേക്ക് പോകാനും കഴിയും.

PLinq ഉം പാരലൽ ക്ലാസും

ടാസ്‌ക്കുകൾക്കും അവയെക്കുറിച്ച് പറഞ്ഞിട്ടുള്ള എല്ലാത്തിനും പുറമേ, .NET-ൽ രസകരമായ രണ്ട് ടൂളുകൾ കൂടിയുണ്ട്: PLinq (Linq2Parallel) ഉം സമാന്തര ക്ലാസും. ഒന്നിലധികം ത്രെഡുകളിലെ എല്ലാ ലിങ്ക് പ്രവർത്തനങ്ങളുടെയും സമാന്തര നിർവ്വഹണം ആദ്യത്തേത് വാഗ്ദാനം ചെയ്യുന്നു. WithDegreeOfParallelism വിപുലീകരണ രീതി ഉപയോഗിച്ച് ത്രെഡുകളുടെ എണ്ണം കോൺഫിഗർ ചെയ്യാവുന്നതാണ്. നിർഭാഗ്യവശാൽ, മിക്കപ്പോഴും PLinq-ന് അതിന്റെ ഡിഫോൾട്ട് മോഡിൽ നിങ്ങളുടെ ഡാറ്റാ ഉറവിടത്തിന്റെ ഇന്റേണലുകളെ കുറിച്ച് കാര്യമായ വേഗത വർദ്ധിപ്പിക്കുന്നതിന് ആവശ്യമായ വിവരങ്ങൾ ഇല്ല, മറുവശത്ത്, ശ്രമിക്കുന്നതിനുള്ള ചെലവ് വളരെ കുറവാണ്: നിങ്ങൾ മുമ്പ് AsParallel രീതി വിളിക്കേണ്ടതുണ്ട്. ലിങ്ക് രീതികളുടെ ശൃംഖലയും പ്രകടന പരിശോധനകളും നടത്തുക. മാത്രമല്ല, പാർട്ടീഷനുകൾ മെക്കാനിസം ഉപയോഗിച്ച് നിങ്ങളുടെ ഡാറ്റാ ഉറവിടത്തിന്റെ സ്വഭാവത്തെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ PLinq-ലേക്ക് കൈമാറാൻ സാധിക്കും. നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ и ഇവിടെ.

സമാന്തര സ്റ്റാറ്റിക് ക്ലാസ് സമാന്തരമായി ഫോറെച്ച് ശേഖരത്തിലൂടെ ആവർത്തിക്കുന്നതിനും ഫോർ ലൂപ്പ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിനും സമാന്തര ഇൻവോക്കിൽ ഒന്നിലധികം ഡെലിഗേറ്റുകളെ എക്സിക്യൂട്ട് ചെയ്യുന്നതിനുമുള്ള രീതികൾ നൽകുന്നു. കണക്കുകൂട്ടലുകൾ പൂർത്തിയാകുന്നതുവരെ നിലവിലെ ത്രെഡിന്റെ നിർവ്വഹണം നിർത്തും. അവസാന ആർഗ്യുമെന്റായി പാരലൽ ഓപ്‌ഷനുകൾ നൽകി ത്രെഡുകളുടെ എണ്ണം കോൺഫിഗർ ചെയ്യാവുന്നതാണ്. ഓപ്‌ഷനുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് TaskScheduler, CancellationToken എന്നിവയും വ്യക്തമാക്കാം.

കണ്ടെത്തലുകൾ

ഞാൻ ഈ ലേഖനം എഴുതാൻ തുടങ്ങിയപ്പോൾ, എന്റെ റിപ്പോർട്ടിലെ സാമഗ്രികളും അതിനുശേഷം എന്റെ ജോലിക്കിടയിൽ ഞാൻ ശേഖരിച്ച വിവരങ്ങളും അടിസ്ഥാനമാക്കി, ഇത് ഇത്രയധികം ഉണ്ടാകുമെന്ന് ഞാൻ പ്രതീക്ഷിച്ചിരുന്നില്ല. ഇപ്പോൾ, ഞാൻ ഈ ലേഖനം ടൈപ്പ് ചെയ്യുന്ന ടെക്സ്റ്റ് എഡിറ്റർ, പേജ് 15 പോയി എന്ന് ആക്ഷേപകരമായി പറയുമ്പോൾ, ഞാൻ ഇടക്കാല ഫലങ്ങൾ സംഗ്രഹിക്കാം. മറ്റ് തന്ത്രങ്ങളും API-കളും വിഷ്വൽ ടൂളുകളും അപകടങ്ങളും അടുത്ത ലേഖനത്തിൽ ഉൾപ്പെടുത്തും.

നിഗമനങ്ങൾ:

• ആധുനിക പിസികളുടെ ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നതിന് ത്രെഡുകൾ, അസിൻക്രണി, പാരലലിസം എന്നിവയിൽ പ്രവർത്തിക്കുന്നതിനുള്ള ഉപകരണങ്ങൾ നിങ്ങൾ അറിഞ്ഞിരിക്കണം.
• .NET-ന് ഈ ആവശ്യങ്ങൾക്കായി നിരവധി വ്യത്യസ്ത ടൂളുകൾ ഉണ്ട്
• അവയെല്ലാം ഒറ്റയടിക്ക് പ്രത്യക്ഷപ്പെട്ടില്ല, അതിനാൽ നിങ്ങൾക്ക് പലപ്പോഴും പാരമ്പര്യമുള്ളവ കണ്ടെത്താനാകും, എന്നിരുന്നാലും, പഴയ API-കൾ കൂടുതൽ പരിശ്രമിക്കാതെ പരിവർത്തനം ചെയ്യാനുള്ള വഴികളുണ്ട്.
• .NET-ലെ ത്രെഡുകളുമായി പ്രവർത്തിക്കുന്നത് ത്രെഡ്, ത്രെഡ്‌പൂൾ ക്ലാസുകൾ പ്രതിനിധീകരിക്കുന്നു
• Thread.Abort, Thread.Interrupt, Win32 API TerminateThread രീതികൾ അപകടകരമാണ്, അവ ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്തിട്ടില്ല. പകരം, CancellationToken മെക്കാനിസം ഉപയോഗിക്കുന്നതാണ് നല്ലത്
• ഒഴുക്ക് വിലപ്പെട്ട ഒരു വിഭവമാണ്, അതിന്റെ വിതരണം പരിമിതമാണ്. പരിപാടികൾക്കായി കാത്തിരിക്കുന്ന ത്രെഡുകൾ തിരക്കുള്ള സാഹചര്യങ്ങൾ ഒഴിവാക്കണം. ഇതിനായി TaskCompletionSource ക്ലാസ് ഉപയോഗിക്കുന്നത് സൗകര്യപ്രദമാണ്
• സമാന്തരതയിലും അസമന്വിതത്തിലും പ്രവർത്തിക്കുന്നതിനുള്ള ഏറ്റവും ശക്തവും നൂതനവുമായ .NET ടൂളുകൾ ടാസ്‌ക്കുകളാണ്.
• c# async/wait operators നോൺ-ബ്ലോക്കിംഗ് വെയിറ്റ് എന്ന ആശയം നടപ്പിലാക്കുന്നു
• TaskScheduler-derived ക്ലാസുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ത്രെഡുകളിലുടനീളം ടാസ്ക്കുകളുടെ വിതരണം നിയന്ത്രിക്കാനാകും
• ഹോട്ട്-പാത്തുകളും മെമ്മറി ട്രാഫിക്കും ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന് ValueTask ഘടന ഉപയോഗപ്രദമാകും
• വിഷ്വൽ സ്റ്റുഡിയോയുടെ ടാസ്‌ക്കുകളും ത്രെഡുകളും വിൻഡോകൾ മൾട്ടി-ത്രെഡഡ് അല്ലെങ്കിൽ അസിൻക്രണസ് കോഡ് ഡീബഗ്ഗിംഗ് ചെയ്യുന്നതിന് ഉപയോഗപ്രദമായ ധാരാളം വിവരങ്ങൾ നൽകുന്നു.
• PLinq ഒരു രസകരമായ ഉപകരണമാണ്, എന്നാൽ നിങ്ങളുടെ ഡാറ്റാ ഉറവിടത്തെക്കുറിച്ച് മതിയായ വിവരങ്ങൾ ഇല്ലായിരിക്കാം, പക്ഷേ പാർട്ടീഷനിംഗ് സംവിധാനം ഉപയോഗിച്ച് ഇത് പരിഹരിക്കാവുന്നതാണ്.
• തുടരേണ്ടത് ...

അവലംബം: www.habr.com