.NET: મલ્ટિથ્રેડીંગ અને અસિંક્રોની સાથે કામ કરવા માટેના સાધનો. ભાગ 1

હું મૂળ લેખ Habr પર પ્રકાશિત કરી રહ્યો છું, જેનો અનુવાદ કોર્પોરેટમાં પોસ્ટ કરવામાં આવ્યો છે બ્લોગ પોસ્ટ.

અહીં અને હવે પરિણામની રાહ જોયા વિના, અસુમેળ રીતે કંઈક કરવાની જરૂર છે, અથવા તે કરી રહેલા ઘણા એકમો વચ્ચે મોટા કાર્યને વિભાજિત કરવાની જરૂર છે, કમ્પ્યુટરના આગમન પહેલાં અસ્તિત્વમાં છે. તેમના આગમન સાથે, આ જરૂરિયાત ખૂબ જ મૂર્ત બની હતી. હવે, 2019 માં, હું આ લેખ 8-કોર ઇન્ટેલ કોર પ્રોસેસર સાથે લેપટોપ પર ટાઇપ કરી રહ્યો છું, જેના પર સો કરતાં વધુ પ્રક્રિયાઓ સમાંતર ચાલી રહી છે, અને તેનાથી પણ વધુ થ્રેડો. નજીકમાં, થોડો ચીંથરેહાલ ફોન છે, જે થોડા વર્ષો પહેલા ખરીદ્યો હતો, તેમાં 8-કોર પ્રોસેસર બોર્ડ પર છે. વિષયોનું સંસાધનો લેખો અને વિડિઓઝથી ભરેલા છે જ્યાં તેમના લેખકો આ વર્ષના ફ્લેગશિપ સ્માર્ટફોન્સની પ્રશંસા કરે છે જે 16-કોર પ્રોસેસર ધરાવે છે. MS Azure 20 કોર પ્રોસેસર અને 128 TB RAM સાથેનું વર્ચ્યુઅલ મશીન $2/કલાકથી ઓછા સમયમાં પૂરું પાડે છે. કમનસીબે, થ્રેડોની ક્રિયાપ્રતિક્રિયાને સંચાલિત કરવામાં સમર્થ થયા વિના મહત્તમ મેળવવા અને આ શક્તિનો ઉપયોગ કરવો અશક્ય છે.

પરિભાષા

પ્રક્રિયા - OS ઑબ્જેક્ટ, અલગ સરનામાંની જગ્યા, થ્રેડો ધરાવે છે.
થ્રેડ - એક OS ઑબ્જેક્ટ, એક્ઝેક્યુશનનું સૌથી નાનું એકમ, પ્રક્રિયાનો ભાગ, થ્રેડો એક પ્રક્રિયાની અંદર મેમરી અને અન્ય સંસાધનો એકબીજામાં વહેંચે છે.
મલ્ટીટાસ્કીંગ - ઓએસ પ્રોપર્ટી, એકસાથે અનેક પ્રક્રિયાઓ ચલાવવાની ક્ષમતા
મલ્ટી-કોર - પ્રોસેસરની મિલકત, ડેટા પ્રોસેસિંગ માટે ઘણા કોરોનો ઉપયોગ કરવાની ક્ષમતા
મલ્ટિપ્રોસેસિંગ - કમ્પ્યુટરની મિલકત, શારીરિક રીતે ઘણા પ્રોસેસરો સાથે એક સાથે કામ કરવાની ક્ષમતા
મલ્ટિથ્રેડીંગ - પ્રક્રિયાની મિલકત, વિવિધ થ્રેડો વચ્ચે ડેટા પ્રોસેસિંગને વિતરિત કરવાની ક્ષમતા.
સમાંતરવાદ - સમયના એકમ દીઠ શારીરિક રીતે એક સાથે અનેક ક્રિયાઓ કરવી
અસિંક્રોની - આ પ્રક્રિયા પૂર્ણ થવાની રાહ જોયા વિના ઑપરેશનનું અમલીકરણ; અમલના પરિણામ પર પછીથી પ્રક્રિયા કરી શકાય છે.

રૂપક

બધી વ્યાખ્યાઓ સારી નથી હોતી અને કેટલીકને વધારાની સમજૂતીની જરૂર હોય છે, તેથી હું ઔપચારિક રીતે રજૂ કરાયેલ પરિભાષામાં નાસ્તો રાંધવા વિશે એક રૂપક ઉમેરીશ. આ રૂપકમાં નાસ્તો રાંધવા એ એક પ્રક્રિયા છે.

સવારે નાસ્તો બનાવતી વખતે હું (સી.પી.યુ) હું રસોડામાં આવું છું (કમ્પ્યુટર). મારી પાસે 2 હાથ છે (કોરો). રસોડામાં સંખ્યાબંધ ઉપકરણો છે (IO): ઓવન, કેટલ, ટોસ્ટર, રેફ્રિજરેટર. હું ગેસ ચાલુ કરું છું, તેના પર ફ્રાઈંગ પાન મૂકું છું અને તે ગરમ થવાની રાહ જોયા વિના તેમાં તેલ રેડું છું (અસુમેળ રીતે, બિન-અવરોધિત-IO-પ્રતીક્ષા), હું ઇંડાને રેફ્રિજરેટરમાંથી બહાર કાઢું છું અને તેને પ્લેટમાં તોડી નાખું છું, પછી તેને એક હાથથી હરાવું છું (થ્રેડ #1), અને બીજું (થ્રેડ #2) પ્લેટ હોલ્ડિંગ (શેર્ડ રિસોર્સ). હવે હું કેટલ ચાલુ કરવા માંગુ છું, પરંતુ મારી પાસે પૂરતા હાથ નથી (થ્રેડ ભૂખમરો) આ સમય દરમિયાન, ફ્રાઈંગ પાન ગરમ થાય છે (પરિણામ પર પ્રક્રિયા કરી રહ્યું છે) જેમાં મેં જે ચાબુક માર્યું છે તે રેડવું. હું કીટલી સુધી પહોંચું છું અને તેને ચાલુ કરું છું અને મૂર્ખતાપૂર્વક તેમાં પાણી ઉકળતું જોઉં છું (અવરોધિત-IO-પ્રતીક્ષા), જો કે આ સમય દરમિયાન તે જ્યાં ઓમેલેટ ચાબુક મારતો હતો તે પ્લેટ ધોઈ શકતો હતો.

મેં ફક્ત 2 હાથનો ઉપયોગ કરીને ઓમેલેટ રાંધ્યું, અને મારી પાસે વધુ નથી, પરંતુ તે જ સમયે, ઓમેલેટને ચાબુક મારવાની ક્ષણે, એક સાથે 3 ઓપરેશન થયા: ઓમેલેટને ચાબુક મારવી, પ્લેટ પકડવી, ફ્રાઈંગ પાન ગરમ કરવી CPU એ કોમ્પ્યુટરનો સૌથી ઝડપી ભાગ છે, IO એ છે જે મોટાભાગે બધું ધીમું પડી જાય છે, તેથી ઘણી વખત અસરકારક ઉકેલ એ છે કે IO માંથી ડેટા પ્રાપ્ત કરતી વખતે CPU ને કંઈક સાથે કબજે કરવું.

રૂપક ચાલુ રાખવું:

• જો આમલેટ તૈયાર કરવાની પ્રક્રિયામાં, હું કપડાં બદલવાનો પણ પ્રયાસ કરીશ, તો આ મલ્ટિટાસ્કિંગનું ઉદાહરણ હશે. એક મહત્વપૂર્ણ સૂક્ષ્મતા: કમ્પ્યુટર્સ આમાં લોકો કરતાં વધુ સારા છે.
• ઘણા રસોઇયાઓ સાથેનું રસોડું, ઉદાહરણ તરીકે રેસ્ટોરન્ટમાં - મલ્ટિ-કોર કમ્પ્યુટર.
• શોપિંગ સેન્ટરમાં ફૂડ કોર્ટમાં ઘણી રેસ્ટોરાં - ડેટા સેન્ટર

.NET સાધનો

.NET અન્ય ઘણી વસ્તુઓની જેમ થ્રેડો સાથે કામ કરવામાં સારું છે. દરેક નવા સંસ્કરણ સાથે, તે તેમની સાથે કામ કરવા માટે વધુ અને વધુ નવા સાધનો રજૂ કરે છે, OS થ્રેડો પર અમૂર્તતાના નવા સ્તરો. એબ્સ્ટ્રેક્શનના નિર્માણ સાથે કામ કરતી વખતે, ફ્રેમવર્ક ડેવલપર્સ એવા અભિગમનો ઉપયોગ કરે છે જે તકને છોડે છે, જ્યારે ઉચ્ચ-સ્તરના એબ્સ્ટ્રેક્શનનો ઉપયોગ કરે છે, ત્યારે એક અથવા વધુ સ્તરો નીચે જવા માટે. મોટેભાગે આ જરૂરી નથી, હકીકતમાં તે શોટગન વડે પોતાને પગમાં ગોળીબાર કરવાનો દરવાજો ખોલે છે, પરંતુ કેટલીકવાર, ભાગ્યે જ કિસ્સાઓમાં, તે સમસ્યાને હલ કરવાનો એકમાત્ર રસ્તો હોઈ શકે છે જે વર્તમાન અમૂર્તતાના સ્તરે ઉકેલી શકાતી નથી. .

ટૂલ્સ દ્વારા, મારો મતલબ ફ્રેમવર્ક અને તૃતીય-પક્ષ પેકેજો દ્વારા પૂરા પાડવામાં આવેલ એપ્લિકેશન પ્રોગ્રામિંગ ઇન્ટરફેસ (APIs), તેમજ સમગ્ર સોફ્ટવેર સોલ્યુશન્સ કે જે મલ્ટી-થ્રેડેડ કોડને લગતી કોઈપણ સમસ્યાઓ માટે શોધને સરળ બનાવે છે.

એક થ્રેડ શરૂ કરી રહ્યા છીએ

થ્રેડ ક્લાસ .NET માં થ્રેડો સાથે કામ કરવા માટેનો સૌથી મૂળભૂત વર્ગ છે. કન્સ્ટ્રક્ટર બેમાંથી એક પ્રતિનિધિ સ્વીકારે છે:

• થ્રેડસ્ટાર્ટ - કોઈ પરિમાણો નથી
• ParametrizedThreadStart - પ્રકાર ઓબ્જેક્ટના એક પરિમાણ સાથે.

સ્ટાર્ટ મેથડને કૉલ કર્યા પછી ડેલિગેટને નવા બનાવેલા થ્રેડમાં એક્ઝિક્યુટ કરવામાં આવશે. જો ParametrizedThreadStart પ્રકારનું પ્રતિનિધિ કન્સ્ટ્રક્ટરને પાસ કરવામાં આવ્યું હોય, તો ઑબ્જેક્ટ સ્ટાર્ટ મેથડમાં પાસ થવો જોઈએ. કોઈપણ સ્થાનિક માહિતીને સ્ટ્રીમમાં સ્થાનાંતરિત કરવા માટે આ પદ્ધતિ જરૂરી છે. તે નોંધવું યોગ્ય છે કે થ્રેડ બનાવવી એ એક ખર્ચાળ કામગીરી છે, અને થ્રેડ પોતે એક ભારે પદાર્થ છે, ઓછામાં ઓછું કારણ કે તે સ્ટેક પર 1MB મેમરી ફાળવે છે અને OS API સાથે ક્રિયાપ્રતિક્રિયાની જરૂર છે.

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

થ્રેડપુલ વર્ગ પૂલના ખ્યાલને રજૂ કરે છે. .NET માં, થ્રેડ પૂલ એ એન્જિનિયરિંગનો એક ભાગ છે, અને માઇક્રોસોફ્ટના વિકાસકર્તાઓએ તે સુનિશ્ચિત કરવા માટે ઘણા પ્રયત્નો કર્યા છે કે તે વિવિધ પરિસ્થિતિઓમાં શ્રેષ્ઠ રીતે કાર્ય કરે છે.

સામાન્ય ખ્યાલ:

એપ્લિકેશન શરૂ થાય તે ક્ષણથી, તે પૃષ્ઠભૂમિમાં અનામતમાં ઘણા થ્રેડો બનાવે છે અને તેમને ઉપયોગ માટે લઈ જવાની ક્ષમતા પ્રદાન કરે છે. જો થ્રેડોનો વારંવાર અને મોટી સંખ્યામાં ઉપયોગ કરવામાં આવે છે, તો પૂલ કોલરની જરૂરિયાતોને પહોંચી વળવા વિસ્તરે છે. જ્યારે યોગ્ય સમયે પૂલમાં કોઈ મુક્ત થ્રેડો ન હોય, ત્યારે તે કાં તો એક થ્રેડોના પાછા આવવાની રાહ જોશે અથવા એક નવો બનાવશે. તે અનુસરે છે કે થ્રેડ પૂલ કેટલીક ટૂંકા ગાળાની ક્રિયાઓ માટે ઉત્તમ છે અને એપ્લિકેશનના સમગ્ર ઓપરેશન દરમિયાન સેવાઓ તરીકે ચાલતી કામગીરી માટે ખરાબ રીતે અનુકૂળ છે.

પૂલમાંથી થ્રેડનો ઉપયોગ કરવા માટે, ત્યાં એક QueueUserWorkItem પદ્ધતિ છે જે WaitCallback પ્રકારના પ્રતિનિધિને સ્વીકારે છે, જે ParametrizedThreadStart જેવી જ સહી ધરાવે છે અને તેને પસાર કરવામાં આવેલ પરિમાણ સમાન કાર્ય કરે છે.

ThreadPool.QueueUserWorkItem(...);

ઓછી જાણીતી થ્રેડ પૂલ પદ્ધતિ RegisterWaitForSingleObject નો ઉપયોગ બિન-અવરોધિત IO કામગીરીને ગોઠવવા માટે થાય છે. જ્યારે વેઇટહેન્ડલ પદ્ધતિને પસાર કરવામાં આવે છે ત્યારે આ પદ્ધતિમાં પસાર કરાયેલ પ્રતિનિધિને કહેવામાં આવશે.

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 માં રજૂ કરવામાં આવી હતી. હવે તે અસિંક્રોની સાથે કામ કરવા માટેનું પ્રમાણભૂત અને મુખ્ય સાધન છે. કોઈપણ કોડ કે જે જૂના અભિગમનો ઉપયોગ કરે છે તેને વારસો ગણવામાં આવે છે. TPL નું મૂળભૂત એકમ System.Threading.Tasks નેમસ્પેસમાંથી કાર્ય વર્ગ છે. કાર્ય એ થ્રેડ પરનું અમૂર્ત છે. C# ભાષાના નવા સંસ્કરણ સાથે, અમને Tasks - async/await operators સાથે કામ કરવાની એક ભવ્ય રીત મળી છે. આ વિભાવનાઓએ અસુમેળ કોડ લખવાનું શક્ય બનાવ્યું જાણે કે તે સરળ અને સિંક્રનસ હોય, આનાથી થ્રેડોની આંતરિક કામગીરીની ઓછી સમજ ધરાવતા લોકો માટે પણ તે શક્ય બન્યું કે તેઓ તેનો ઉપયોગ કરતી એપ્લિકેશનો લખી શકે, લાંબી કામગીરી કરતી વખતે સ્થિર થતી ન હોય તેવી એપ્લિકેશનો. async/await નો ઉપયોગ એ એક અથવા તો ઘણા લેખો માટેનો વિષય છે, પરંતુ હું થોડા વાક્યોમાં તેનો સારાંશ મેળવવાનો પ્રયાસ કરીશ:

• async એ કાર્ય અથવા રદબાતલ પરત કરતી પદ્ધતિનું મોડિફાયર છે
• અને await એ નોન-બ્લોકીંગ ટાસ્ક વેઈટીંગ ઓપરેટર છે.

ફરી એકવાર: પ્રતીક્ષા ઓપરેટર, સામાન્ય કિસ્સામાં (ત્યાં અપવાદો છે), અમલના વર્તમાન થ્રેડને વધુ બહાર પાડશે, અને જ્યારે કાર્ય તેના અમલને પૂર્ણ કરશે, અને થ્રેડ (હકીકતમાં, સંદર્ભ કહેવું વધુ યોગ્ય રહેશે. , પરંતુ તેના પર પછીથી વધુ) પદ્ધતિને આગળ ચલાવવાનું ચાલુ રાખશે. .NET ની અંદર, આ મિકેનિઝમ યીલ્ડ રિટર્નની જેમ જ લાગુ કરવામાં આવે છે, જ્યારે લેખિત પદ્ધતિ સંપૂર્ણ વર્ગમાં ફેરવાય છે, જે એક રાજ્ય મશીન છે અને આ રાજ્યોના આધારે અલગ ટુકડાઓમાં અમલ કરી શકાય છે. રસ ધરાવતી કોઈપણ વ્યક્તિ asynс/await નો ઉપયોગ કરીને કોઈપણ સરળ કોડ લખી શકે છે, કમ્પાઈલર જનરેટેડ કોડ સક્ષમ સાથે JetBrains dotPeek નો ઉપયોગ કરીને એસેમ્બલીને કમ્પાઈલ અને જોઈ શકે છે.

ચાલો ટાસ્કને લોન્ચ કરવા અને તેનો ઉપયોગ કરવા માટેના વિકલ્પો જોઈએ. નીચેના કોડ ઉદાહરણમાં, અમે એક નવું કાર્ય બનાવીએ છીએ જે કંઈપણ ઉપયોગી નથી (થ્રેડ.સ્લીપ(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 - કાર્યોને પદાનુક્રમમાં ગોઠવી શકાય છે. જો આ વિકલ્પનો ઉપયોગ કરવામાં આવ્યો હોય, તો કાર્ય એવી સ્થિતિમાં હોઈ શકે છે જ્યાં તેણે પોતે પૂર્ણ કર્યું છે અને તેના બાળકોના અમલની રાહ જોઈ રહ્યું છે.
• PreferFairness - એનો અર્થ એ છે કે અમલ માટે મોકલવામાં આવેલ ટાસ્કને પાછળથી મોકલવામાં આવે તે પહેલાં એક્ઝિક્યુટ કરવું વધુ સારું રહેશે. પરંતુ આ માત્ર એક ભલામણ છે અને પરિણામોની ખાતરી નથી.

પદ્ધતિમાં પસાર થયેલ બીજું પરિમાણ છે CancellationToken. ઑપરેશન શરૂ થયા પછી તેને રદ કરવાનું યોગ્ય રીતે હેન્ડલ કરવા માટે, એક્ઝિક્યુટ કરવામાં આવેલ કોડ કેન્સલેશન ટોકન સ્ટેટ માટે ચેકથી ભરેલો હોવો જોઈએ. જો ત્યાં કોઈ ચેક ન હોય, તો CancellationTokenSource ઑબ્જેક્ટ પર કૉલ કરેલ રદ કરવાની પદ્ધતિ, કાર્ય શરૂ થાય તે પહેલાં જ તેના અમલને રોકવા માટે સક્ષમ હશે.

છેલ્લું પરિમાણ એ TaskScheduler પ્રકારનું શેડ્યૂલર ઑબ્જેક્ટ છે. આ વર્ગ અને તેના વંશજો સમગ્ર થ્રેડોમાં કાર્યોને વિતરિત કરવા માટેની વ્યૂહરચનાઓને નિયંત્રિત કરવા માટે રચાયેલ છે; મૂળભૂત રીતે, કાર્ય પૂલમાંથી રેન્ડમ થ્રેડ પર ચલાવવામાં આવશે.

પ્રતીક્ષા ઓપરેટર બનાવેલ કાર્ય પર લાગુ થાય છે, જેનો અર્થ છે કે તેના પછી લખાયેલ કોડ, જો ત્યાં એક હોય, તો તે જ સંદર્ભમાં અમલમાં આવશે (ઘણી વખત આનો અર્થ એ જ થ્રેડ પર થાય છે) જે પ્રતીક્ષા કરતા પહેલા કોડ હતો.

પદ્ધતિ async void તરીકે ચિહ્નિત થયેલ છે, જેનો અર્થ છે કે તે રાહ ઓપરેટરનો ઉપયોગ કરી શકે છે, પરંતુ કૉલિંગ કોડ અમલ માટે રાહ જોઈ શકશે નહીં. જો આવી સુવિધા જરૂરી હોય, તો પદ્ધતિએ કાર્ય પરત કરવું આવશ્યક છે. async void તરીકે ચિહ્નિત કરેલી પદ્ધતિઓ એકદમ સામાન્ય છે: એક નિયમ તરીકે, આ ઇવેન્ટ હેન્ડલર્સ અથવા અન્ય પદ્ધતિઓ છે જે આગ પર કામ કરે છે અને સિદ્ધાંતને ભૂલી જાય છે. જો તમારે માત્ર એક્ઝેક્યુશનના અંત સુધી રાહ જોવાની તક આપવાની જરૂર નથી, પરંતુ પરિણામ પણ પરત કરવાની જરૂર છે, તો તમારે કાર્યનો ઉપયોગ કરવાની જરૂર છે.

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 નો ઉપયોગ કરતી વખતે અસુમેળ કોડમાંની ભૂલો હેન્ડલ કરવા માટે ખૂબ જ સરળ છે - તે કોડ સિંક્રનસ હોય તો તે જ રીતે વર્તે છે. જો આપણે કાર્ય માટે સિંક્રનસ રાહ વળગાડ મુક્તિ લાગુ કરીએ, તો મૂળ અપવાદ એગ્રિગેટ એક્સેપ્શનમાં ફેરવાય છે, એટલે કે. અપવાદને હેન્ડલ કરવા માટે, તમારે InnerException પ્રકારનું પરીક્ષણ કરવું પડશે અને C# વિશ્વમાં વધુ પરિચિત કેચ બ્લોક્સની સાંકળને બદલે, એક કેચ બ્લોકની અંદર જાતે જો સાંકળ લખવી પડશે અથવા જ્યારે બાંધવામાં આવે ત્યારે કેચનો ઉપયોગ કરવો પડશે.

ત્રીજા અને અંતિમ ઉદાહરણોને પણ આ જ કારણસર ખરાબ તરીકે ચિહ્નિત કરવામાં આવ્યા છે અને તેમાં બધી સમાન સમસ્યાઓ છે.

જ્યારે કોઈપણ અને ક્યારે બધી પદ્ધતિઓ કાર્યોના જૂથની રાહ જોવા માટે અત્યંત અનુકૂળ છે; તેઓ કાર્યોના જૂથને એકમાં લપેટી દે છે, જે કાં તો જ્યારે જૂથમાંથી કોઈ કાર્ય પ્રથમ ટ્રિગર થાય છે અથવા જ્યારે તે બધાએ તેમનો અમલ પૂર્ણ કરી લીધો હોય ત્યારે ફાયર થશે.

થ્રેડો અટકાવી રહ્યા છીએ

વિવિધ કારણોસર, પ્રવાહ શરૂ થયા પછી તેને રોકવાની જરૂર પડી શકે છે. આ કરવા માટે ઘણી બધી રીતો છે. થ્રેડ વર્ગમાં બે યોગ્ય નામવાળી પદ્ધતિઓ છે: છોડી દો и ઇન્ટરપ્ટ. પ્રથમ એક ખૂબ ઉપયોગ માટે આગ્રહણીય નથી, કારણ કે કોઈપણ રેન્ડમ ક્ષણે તેને કૉલ કર્યા પછી, કોઈપણ સૂચનાની પ્રક્રિયા દરમિયાન, એક અપવાદ ફેંકવામાં આવશે ThreadAbortedException. કોઈપણ પૂર્ણાંક ચલને વધારતી વખતે તમે આવા અપવાદની અપેક્ષા રાખતા નથી, ખરું ને? અને આ પદ્ધતિનો ઉપયોગ કરતી વખતે, આ એક ખૂબ જ વાસ્તવિક પરિસ્થિતિ છે. જો તમારે CLR ને કોડના ચોક્કસ વિભાગમાં આવો અપવાદ જનરેટ કરવાથી રોકવાની જરૂર હોય, તો તમે તેને કૉલમાં લપેટી શકો છો. થ્રેડ. BeginCriticalRegion, Thread.EndCriticalRegion. આખરી બ્લોકમાં લખાયેલ કોઈપણ કોડ આવા કૉલ્સમાં આવરિત હોય છે. આ કારણોસર, ફ્રેમવર્ક કોડની ઊંડાઈમાં તમે ખાલી પ્રયાસ સાથે બ્લોક્સ શોધી શકો છો, પરંતુ અંતે ખાલી નહીં. માઈક્રોસોફ્ટ આ પદ્ધતિને એટલો નિરુત્સાહિત કરે છે કે તેઓએ તેને .net કોરમાં સમાવી નથી.

વિક્ષેપ પદ્ધતિ વધુ અનુમાનિત રીતે કામ કરે છે. તે અપવાદ સાથે થ્રેડને વિક્ષેપિત કરી શકે છે ThreadInterruptedException માત્ર તે ક્ષણો દરમિયાન જ્યારે થ્રેડ રાહ જોવાની સ્થિતિમાં હોય. વેઇટહેન્ડલ, લોક અથવા થ્રેડ.સ્લીપને કૉલ કર્યા પછી રાહ જોતી વખતે લટકતી વખતે તે આ સ્થિતિમાં પ્રવેશ કરે છે.

ઉપર વર્ણવેલ બંને વિકલ્પો ખરાબ છે કારણ કે તે અણધારી છે. ઉકેલ એ સ્ટ્રક્ચરનો ઉપયોગ કરવાનો છે રદ્દીકરણ ટોકન અને વર્ગ કેન્સલેશન ટોકનસોર્સ. મુદ્દો આ છે: કેન્સલેશન ટોકનસોર્સ ક્લાસનો એક દાખલો બનાવવામાં આવ્યો છે અને જે તેની માલિકી ધરાવે છે તે જ પદ્ધતિને કૉલ કરીને ઓપરેશનને રોકી શકે છે. રદ કરો. માત્ર કેન્સલેશન ટોકન જ ઑપરેશનમાં જ પસાર થાય છે. CancellationToken માલિકો પોતે ઓપરેશન રદ કરી શકતા નથી, પરંતુ ઓપરેશન રદ કરવામાં આવ્યું છે કે કેમ તે માત્ર તપાસી શકે છે. આ માટે બુલિયન પ્રોપર્ટી છે રદ કરવાની વિનંતી કરી છે અને પદ્ધતિ ThrowIfCancelRequested. બાદમાં અપવાદ ફેંકશે TaskCancelledException જો કેન્સલેશન ટોકન દાખલાને પોપટ કરવામાં આવે તો કેન્સલ પદ્ધતિને બોલાવવામાં આવી હતી. અને આ તે પદ્ધતિ છે જેનો હું ઉપયોગ કરવાની ભલામણ કરું છું. અપવાદ કામગીરી કયા બિંદુએ બંધ કરી શકાય તેના પર સંપૂર્ણ નિયંત્રણ મેળવીને અગાઉના વિકલ્પો કરતાં આ સુધારો છે.

થ્રેડને રોકવા માટેનો સૌથી ઘાતકી વિકલ્પ Win32 API ટર્મિનેટ થ્રેડ ફંક્શનને કૉલ કરવાનો છે. આ ફંક્શનને કૉલ કર્યા પછી CLR નું વર્તન અણધારી હોઈ શકે છે. MSDN પર આ ફંક્શન વિશે નીચે લખેલું છે: "TerminateThread એ એક ખતરનાક કાર્ય છે જેનો ઉપયોગ ફક્ત અત્યંત આત્યંતિક કેસોમાં થવો જોઈએ. "

FromAsync પદ્ધતિનો ઉપયોગ કરીને લેગસી API ને કાર્ય આધારિત માં રૂપાંતરિત કરવું

જો તમે એવા પ્રોજેક્ટ પર કામ કરવા માટે પૂરતા ભાગ્યશાળી છો કે જે ટાસ્ક્સ રજૂ થયા પછી શરૂ કરવામાં આવ્યું હતું અને મોટાભાગના વિકાસકર્તાઓ માટે શાંત ભયાનકતા પેદા કરવાનું બંધ કરી દીધું હતું, તો તમારે ઘણા બધા જૂના API, બંને તૃતીય-પક્ષ અને તમારી ટીમ સાથે વ્યવહાર કરવો પડશે નહીં. ભૂતકાળમાં ત્રાસ આપ્યો છે. સદભાગ્યે, .NET ફ્રેમવર્ક ટીમે અમારી સંભાળ લીધી, જો કે કદાચ ધ્યેય આપણી સંભાળ રાખવાનો હતો. તે ગમે તેટલું હોય, .NET પાસે જૂના અસુમેળ પ્રોગ્રામિંગ અભિગમોમાં લખેલા કોડને પીડારહિત રીતે નવામાં કન્વર્ટ કરવા માટે ઘણા બધા ટૂલ્સ છે. તેમાંથી એક ટાસ્કફૅક્ટરીની FromAsync પદ્ધતિ છે. નીચેના કોડ ઉદાહરણમાં, આ પદ્ધતિનો ઉપયોગ કરીને હું WebRequest વર્ગની જૂની async પદ્ધતિઓને કાર્યમાં લપેટીશ.

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

આ માત્ર એક ઉદાહરણ છે અને તમારે આ બિલ્ટ-ઇન પ્રકારો સાથે કરવું પડે તેવી શક્યતા નથી, પરંતુ કોઈપણ જૂનો પ્રોજેક્ટ ફક્ત BeginDoSomething પદ્ધતિઓથી ભરપૂર હોય છે જે તેને પ્રાપ્ત કરતી IAsyncResult અને EndDoSomething પદ્ધતિઓ પરત કરે છે.

TaskCompletionSource વર્ગનો ઉપયોગ કરીને લેગસી API ને Task Based માં કન્વર્ટ કરો

ધ્યાનમાં લેવાનું બીજું મહત્વનું સાધન એ વર્ગ છે TaskCompletionSource. કાર્યો, હેતુ અને કામગીરીના સિદ્ધાંતના સંદર્ભમાં, તે થ્રેડપુલ વર્ગની RegisterWaitForSingleObject પદ્ધતિની કંઈક અંશે યાદ અપાવે છે, જેના વિશે મેં ઉપર લખ્યું છે. આ વર્ગનો ઉપયોગ કરીને, તમે કાર્યમાં જૂના અસુમેળ API ને સરળતાથી અને સહેલાઇથી લપેટી શકો છો.

તમે કહેશો કે મેં પહેલેથી જ આ હેતુઓ માટે બનાવાયેલ TaskFactory વર્ગની FromAsync પદ્ધતિ વિશે વાત કરી છે. અહીં આપણે .net માં અસુમેળ મોડલ્સના વિકાસના સમગ્ર ઇતિહાસને યાદ રાખવાનો રહેશે જે માઇક્રોસોફ્ટે છેલ્લા 15 વર્ષોમાં ઓફર કર્યો છે: ટાસ્ક-બેઝ્ડ અસિંક્રોનસ પેટર્ન (TAP) પહેલાં, ત્યાં અસિંક્રોનસ પ્રોગ્રામિંગ પેટર્ન (APP) હતી, જે પદ્ધતિઓ વિશે હતું શરૂઆતશું કંઈક પરત IAsyncResult અને પદ્ધતિઓ અંતDoSomething કે જે તેને સ્વીકારે છે અને આ વર્ષોના વારસા માટે FromAsync પદ્ધતિ એકદમ પરફેક્ટ છે, પરંતુ સમય જતાં, તેને ઇવેન્ટ આધારિત અસિંક્રોનસ પેટર્ન (ઇએપી), જે ધારે છે કે જ્યારે અસુમેળ કામગીરી પૂર્ણ થશે ત્યારે ઘટના ઊભી થશે.

TaskCompletionSource ઇવેન્ટ મૉડલની આસપાસ બનેલા Tasks અને લેગસી API ને લપેટવા માટે યોગ્ય છે. તેના કાર્યનો સાર નીચે મુજબ છે: આ વર્ગના ઑબ્જેક્ટમાં ટાસ્ક પ્રકારની જાહેર મિલકત છે, જેની સ્થિતિને TaskCompletionSource વર્ગની SetResult, SetException વગેરે પદ્ધતિઓ દ્વારા નિયંત્રિત કરી શકાય છે. સ્થાનો પર જ્યાં રાહ ઓપરેટર આ કાર્ય માટે લાગુ કરવામાં આવ્યું હતું, તે TaskCompletionSource પર લાગુ કરાયેલ પદ્ધતિના આધારે અપવાદ સાથે ચલાવવામાં આવશે અથવા નિષ્ફળ જશે. જો તે હજુ પણ સ્પષ્ટ નથી, તો ચાલો આ કોડ ઉદાહરણ જોઈએ, જ્યાં કેટલાક જૂના 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 નો ઉપયોગ કરીને જૂના API ને વીંટાળવું એટલું જ નથી. આ વર્ગનો ઉપયોગ થ્રેડો પર કબજો ન કરતા કાર્યો પર વિવિધ API ને ડિઝાઇન કરવાની રસપ્રદ સંભાવના ખોલે છે. અને સ્ટ્રીમ, જેમ આપણે યાદ રાખીએ છીએ, એક ખર્ચાળ સંસાધન છે અને તેમની સંખ્યા મર્યાદિત છે (મુખ્યત્વે RAM ની માત્રા દ્વારા). આ મર્યાદા વિકાસ દ્વારા સરળતાથી પ્રાપ્ત કરી શકાય છે, ઉદાહરણ તરીકે, જટિલ વ્યવસાય તર્ક સાથે લોડ કરેલ વેબ એપ્લિકેશન. લોંગ-પોલીંગ જેવી યુક્તિનો અમલ કરતી વખતે હું જે શક્યતાઓ વિશે વાત કરી રહ્યો છું તેના પર ચાલો વિચાર કરીએ.

ટૂંકમાં, યુક્તિનો સાર આ છે: તમારે તેની બાજુમાં બનતી કેટલીક ઘટનાઓ વિશે API પાસેથી માહિતી પ્રાપ્ત કરવાની જરૂર છે, જ્યારે API કેટલાક કારણોસર ઘટનાની જાણ કરી શકતું નથી, પરંતુ ફક્ત રાજ્ય પરત કરી શકે છે. આનું ઉદાહરણ WebSocket ના સમય પહેલા અથવા જ્યારે આ ટેક્નોલોજીનો ઉપયોગ કોઈ કારણોસર અશક્ય હતું ત્યારે HTTP ની ટોચ પર બનેલ તમામ API છે. ક્લાયંટ HTTP સર્વરને પૂછી શકે છે. HTTP સર્વર પોતે ક્લાયંટ સાથે વાતચીત શરૂ કરી શકતું નથી. ટાઈમરનો ઉપયોગ કરીને સર્વરનું મતદાન કરવું એ એક સરળ ઉપાય છે, પરંતુ આનાથી સર્વર પર વધારાનો ભાર પડે છે અને સરેરાશ TimerInterval/2 પર વધારાનો વિલંબ થાય છે. આની આસપાસ જવા માટે, લોંગ પોલિંગ નામની યુક્તિની શોધ કરવામાં આવી હતી, જેમાં પ્રતિભાવમાં વિલંબનો સમાવેશ થાય છે. સર્વર જ્યાં સુધી સમયસમાપ્તિ સમાપ્ત ન થાય અથવા ઇવેન્ટ થશે. જો કોઈ ઘટના બને છે, તો તેની પ્રક્રિયા કરવામાં આવે છે; જો નહીં, તો વિનંતી ફરીથી મોકલવામાં આવે છે.

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 ઓપરેટરો, જેમ કે યીલ્ડ રીટર્ન ઓપરેટર, પદ્ધતિમાંથી સ્ટેટ મશીન જનરેટ કરે છે, અને આ એક નવા ઑબ્જેક્ટનું નિર્માણ છે, જે લગભગ હંમેશા મહત્વનું નથી હોતું, પરંતુ ભાગ્યે જ કિસ્સાઓમાં તે સમસ્યા ઊભી કરી શકે છે. આ કેસ એવી પદ્ધતિ હોઈ શકે છે જેને ખરેખર વારંવાર કહેવામાં આવે છે, અમે દસ અને સેંકડો હજારો કૉલ્સ વિશે વાત કરી રહ્યા છીએ. જો આવી પદ્ધતિ એવી રીતે લખવામાં આવે છે કે મોટા ભાગના કિસ્સાઓમાં તે તમામ પ્રતીક્ષા પદ્ધતિઓને બાયપાસ કરીને પરિણામ આપે છે, તો .NET આને ઑપ્ટિમાઇઝ કરવા માટે એક સાધન પૂરું પાડે છે - ValueTask માળખું. તેને સ્પષ્ટ કરવા માટે, ચાલો તેના ઉપયોગનું ઉદાહરણ જોઈએ: ત્યાં એક કેશ છે જે આપણે ઘણી વાર જઈએ છીએ. તેમાં કેટલાક મૂલ્યો છે અને પછી અમે તેને ફક્ત પરત કરીએ છીએ; જો નહીં, તો અમે તેને મેળવવા માટે કેટલાક ધીમા IO પર જઈએ છીએ. હું બાદમાં અસુમેળ રીતે કરવા માંગુ છું, જેનો અર્થ છે કે સમગ્ર પદ્ધતિ અસુમેળ હોવાનું બહાર આવ્યું છે. આમ, પદ્ધતિ લખવાની સ્પષ્ટ રીત નીચે મુજબ છે:

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

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

થોડું ઑપ્ટિમાઇઝ કરવાની ઇચ્છાને કારણે, અને આ કોડને કમ્પાઇલ કરતી વખતે રોઝલિન શું જનરેટ કરશે તેના સહેજ ડરને કારણે, તમે આ ઉદાહરણને નીચે પ્રમાણે ફરીથી લખી શકો છો:

public Task<string> GetById(int id) {

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

ખરેખર, આ કિસ્સામાં શ્રેષ્ઠ ઉકેલ એ હોટ-પાથને ઑપ્ટિમાઇઝ કરવાનો છે, એટલે કે, કોઈપણ બિનજરૂરી ફાળવણી અને GC પર લોડ કર્યા વિના શબ્દકોશમાંથી મૂલ્ય મેળવવું, જ્યારે તે દુર્લભ કિસ્સાઓમાં જ્યારે આપણે હજી પણ ડેટા માટે IO પર જવાની જરૂર હોય. , બધું જૂની રીતે વત્તા/માઈનસ રહેશે:

public ValueTask<string> GetById(int id) {

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

ચાલો કોડના આ ભાગ પર નજીકથી નજર કરીએ: જો કેશમાં કોઈ મૂલ્ય હોય, તો અમે એક માળખું બનાવીએ છીએ, અન્યથા વાસ્તવિક કાર્ય અર્થપૂર્ણ એકમાં આવરિત થઈ જશે. કૉલિંગ કોડ આ કોડને કયા પાથમાં એક્ઝિક્યુટ કરવામાં આવ્યો હતો તેની પરવા કરતું નથી: ValueTask, C# સિન્ટેક્સના દૃષ્ટિકોણથી, આ કિસ્સામાં નિયમિત કાર્ય જેવું જ વર્તન કરશે.

TaskSchedulers: ટાસ્ક લોંચ વ્યૂહરચનાનું સંચાલન કરવું

આગામી API કે જે હું ધ્યાનમાં લેવા માંગુ છું તે વર્ગ છે કાર્ય અનુસૂચિ અને તેના ડેરિવેટિવ્ઝ. મેં ઉપર પહેલેથી જ ઉલ્લેખ કર્યો છે કે TPL પાસે સમગ્ર થ્રેડો પર કાર્યોનું વિતરણ કરવા માટેની વ્યૂહરચનાઓનું સંચાલન કરવાની ક્ષમતા છે. આવી વ્યૂહરચનાઓ TaskScheduler વર્ગના વંશજોમાં વ્યાખ્યાયિત કરવામાં આવી છે. તમને જરૂર પડી શકે તેવી લગભગ કોઈપણ વ્યૂહરચના પુસ્તકાલયમાં મળી શકે છે. સમાંતર એક્સ્ટેન્શન્સ એક્સ્ટ્રાઝ, માઇક્રોસોફ્ટ દ્વારા વિકસિત, પરંતુ .NET નો ભાગ નથી, પરંતુ Nuget પેકેજ તરીકે પૂરા પાડવામાં આવેલ છે. ચાલો તેમાંથી કેટલાકને સંક્ષિપ્તમાં જોઈએ:

• CurrentThreadTaskScheduler — વર્તમાન થ્રેડ પર કાર્યો ચલાવે છે
• લિમિટેડ કન્કરન્સી લેવલ ટાસ્ક શેડ્યુલર — પરિમાણ N દ્વારા વારાફરતી ચલાવવામાં આવતા કાર્યોની સંખ્યાને મર્યાદિત કરે છે, જે કન્સ્ટ્રક્ટરમાં સ્વીકારવામાં આવે છે.
• ઓર્ડર કરેલ ટાસ્ક શેડ્યુલર — LimitedConcurrencyLevelTaskScheduler(1) તરીકે વ્યાખ્યાયિત થયેલ છે, તેથી કાર્યો ક્રમિક રીતે ચલાવવામાં આવશે.
• WorkStealingTaskScheduler - ઓજારો કામની ચોરી કાર્ય વિતરણ માટે અભિગમ. આવશ્યકપણે તે એક અલગ થ્રેડપૂલ છે. સમસ્યાનું નિરાકરણ કરે છે કે .NET ThreadPool માં એક સ્થિર વર્ગ છે, જે બધી એપ્લિકેશનો માટે એક છે, જેનો અર્થ છે કે પ્રોગ્રામના એક ભાગમાં તેનો ઓવરલોડિંગ અથવા ખોટો ઉપયોગ બીજા ભાગમાં આડઅસરો તરફ દોરી શકે છે. તદુપરાંત, આવી ખામીઓનું કારણ સમજવું અત્યંત મુશ્કેલ છે. તે. પ્રોગ્રામના એવા ભાગોમાં અલગ વર્કસ્ટેલિંગ ટાસ્ક શેડ્યૂલર્સનો ઉપયોગ કરવાની જરૂર પડી શકે છે જ્યાં થ્રેડપુલનો ઉપયોગ આક્રમક અને અણધારી હોઈ શકે છે.
• કતારબદ્ધટાસ્ક શેડ્યુલર — તમને અગ્રતા કતારના નિયમો અનુસાર કાર્યો કરવા દે છે
• ThreadPerTaskScheduler — દરેક કાર્ય માટે એક અલગ થ્રેડ બનાવે છે જે તેના પર ચલાવવામાં આવે છે. એવા કાર્યો માટે ઉપયોગી થઈ શકે છે જે પૂર્ણ થવામાં અણધારી રીતે લાંબો સમય લે છે.

એક સરસ વિગતવાર છે લેખ માઇક્રોસોફ્ટ બ્લોગ પર TaskSchedulers વિશે.

Tasks થી સંબંધિત દરેક વસ્તુના અનુકૂળ ડીબગીંગ માટે, વિઝ્યુઅલ સ્ટુડિયો પાસે Tasks વિન્ડો છે. આ વિંડોમાં તમે કાર્યની વર્તમાન સ્થિતિ જોઈ શકો છો અને કોડની હાલમાં એક્ઝેક્યુટીંગ લાઇન પર જાઓ.

PLinq અને સમાંતર વર્ગ

Tasks અને તેમના વિશે જણાવેલ દરેક વસ્તુ ઉપરાંત, .NET માં વધુ બે રસપ્રદ સાધનો છે: PLinq (Linq2Parallel) અને સમાંતર વર્ગ. પ્રથમ બહુવિધ થ્રેડો પર તમામ Linq કામગીરીના સમાંતર અમલનું વચન આપે છે. થ્રેડોની સંખ્યા WithDegreeOfParallelism એક્સ્ટેંશન પદ્ધતિનો ઉપયોગ કરીને ગોઠવી શકાય છે. કમનસીબે, મોટાભાગે તેના ડિફૉલ્ટ મોડમાં PLinq પાસે તમારા ડેટા સ્ત્રોતના આંતરિક વિશે પૂરતી માહિતી નથી હોતી જેથી કરીને નોંધપાત્ર ઝડપ પ્રાપ્ત કરી શકાય, બીજી તરફ, પ્રયાસ કરવાની કિંમત ઘણી ઓછી હોય છે: તમારે પહેલા AsParallel પદ્ધતિને કૉલ કરવાની જરૂર છે. Linq પદ્ધતિઓની સાંકળ અને પ્રદર્શન પરીક્ષણો ચલાવો. વધુમાં, પાર્ટીશનો મિકેનિઝમનો ઉપયોગ કરીને તમારા ડેટા સ્ત્રોતની પ્રકૃતિ વિશે PLinq ને વધારાની માહિતી મોકલવી શક્ય છે. તમે વધુ વાંચી શકો છો અહીં и અહીં.

સમાંતર સ્ટેટિક ક્લાસ સમાંતરમાં ફોરેચ કલેક્શન દ્વારા પુનરાવર્તિત કરવા, ફોર લૂપ ચલાવવા અને સમાંતર ઇન્વોકમાં બહુવિધ પ્રતિનિધિઓને ચલાવવા માટેની પદ્ધતિઓ પ્રદાન કરે છે. ગણતરીઓ પૂર્ણ ન થાય ત્યાં સુધી વર્તમાન થ્રેડનું અમલીકરણ અટકાવવામાં આવશે. છેલ્લી દલીલ તરીકે ParallelOptions પસાર કરીને થ્રેડોની સંખ્યા ગોઠવી શકાય છે. તમે વિકલ્પોનો ઉપયોગ કરીને TaskScheduler અને CancellationToken નો પણ ઉલ્લેખ કરી શકો છો.

તારણો

જ્યારે મેં મારા અહેવાલની સામગ્રી અને તેના પછીના મારા કાર્ય દરમિયાન મેં એકત્રિત કરેલી માહિતીના આધારે આ લેખ લખવાનું શરૂ કર્યું, ત્યારે મને આશા નહોતી કે તેમાં આટલું બધું હશે. હવે, જ્યારે ટેક્સ્ટ એડિટર કે જેમાં હું આ લેખ લખી રહ્યો છું તે નિંદાપૂર્વક મને કહે છે કે પૃષ્ઠ 15 ગયું છે, હું વચગાળાના પરિણામોનો સારાંશ આપીશ. અન્ય યુક્તિઓ, APIs, વિઝ્યુઅલ ટૂલ્સ અને મુશ્કેલીઓ આગામી લેખમાં આવરી લેવામાં આવશે.

તારણો:

• આધુનિક પીસીના સંસાધનોનો ઉપયોગ કરવા માટે તમારે થ્રેડો, અસુમેળ અને સમાનતા સાથે કામ કરવા માટેના સાધનો જાણવાની જરૂર છે.
• આ હેતુઓ માટે .NET પાસે ઘણાં વિવિધ સાધનો છે
• તે બધા એક જ સમયે દેખાયા નથી, તેથી તમે વારંવાર લેગસી શોધી શકો છો, જો કે, ઘણા પ્રયત્નો વિના જૂના API ને કન્વર્ટ કરવાની રીતો છે.
• .NET માં થ્રેડો સાથે કામ કરવું એ થ્રેડ અને થ્રેડપૂલ વર્ગો દ્વારા રજૂ થાય છે
• Thread.Abort, Thread.Interrupt અને Win32 API TerminateThread પદ્ધતિઓ ખતરનાક છે અને ઉપયોગ માટે ભલામણ કરવામાં આવતી નથી. તેના બદલે, કેન્સલેશન ટોકન મિકેનિઝમનો ઉપયોગ કરવો વધુ સારું છે
• પ્રવાહ એ એક મૂલ્યવાન સંસાધન છે અને તેનો પુરવઠો મર્યાદિત છે. ઘટનાઓની રાહ જોવામાં થ્રેડો વ્યસ્ત હોય તેવી પરિસ્થિતિઓ ટાળવી જોઈએ. આ માટે TaskCompletionSource વર્ગનો ઉપયોગ કરવો અનુકૂળ છે
• સમાનતા અને અસુમેળ સાથે કામ કરવા માટેના સૌથી શક્તિશાળી અને અદ્યતન .NET ટૂલ્સ છે Tasks.
• c# async/await ઓપરેટરો નોન-બ્લોકીંગ વેઈટનો ખ્યાલ અમલમાં મૂકે છે
• તમે TaskScheduler દ્વારા મેળવેલા વર્ગોનો ઉપયોગ કરીને સમગ્ર થ્રેડોમાં Tasksના વિતરણને નિયંત્રિત કરી શકો છો
• ValueTask માળખું હોટ-પાથ અને મેમરી-ટ્રાફિકને ઑપ્ટિમાઇઝ કરવામાં ઉપયોગી થઈ શકે છે
• વિઝ્યુઅલ સ્ટુડિયોના કાર્યો અને થ્રેડ્સ વિન્ડો મલ્ટી-થ્રેડેડ અથવા અસુમેળ કોડને ડિબગ કરવા માટે ઘણી બધી ઉપયોગી માહિતી પ્રદાન કરે છે.
• PLinq એ એક સરસ સાધન છે, પરંતુ તેમાં તમારા ડેટા સ્ત્રોત વિશે પૂરતી માહિતી ન હોઈ શકે, પરંતુ પાર્ટીશનીંગ મિકેનિઝમનો ઉપયોગ કરીને તેને ઠીક કરી શકાય છે.
• ચાલુ રહી શકાય…

સોર્સ: www.habr.com