.NET: মাল্টিথ্রেডিং এবং অ্যাসিঙ্ক্রোনির সাথে কাজ করার জন্য টুল। অংশ 1

আমি হাবরের মূল নিবন্ধটি প্রকাশ করছি, যার অনুবাদ কর্পোরেটে পোস্ট করা হয়েছে ব্লগ পোস্ট.

এখানে এবং এখন ফলাফলের জন্য অপেক্ষা না করে অসিঙ্ক্রোনাসভাবে কিছু করার প্রয়োজন বা এটি সম্পাদনকারী কয়েকটি ইউনিটের মধ্যে বড় কাজ ভাগ করার প্রয়োজন কম্পিউটারের আবির্ভাবের আগে বিদ্যমান ছিল। তাদের আবির্ভাবের সাথে, এই প্রয়োজনটি খুব বাস্তব হয়ে ওঠে। এখন, 2019 সালে, আমি একটি 8-কোর ইন্টেল কোর প্রসেসর সহ একটি ল্যাপটপে এই নিবন্ধটি টাইপ করছি, যার উপর একশোরও বেশি প্রসেস সমান্তরালভাবে চলছে, এমনকি আরও বেশি থ্রেড। কাছাকাছি, একটি সামান্য জর্জরিত ফোন আছে, কয়েক বছর আগে কেনা, এটি বোর্ডে একটি 8-কোর প্রসেসর আছে। থিম্যাটিক সংস্থানগুলি নিবন্ধ এবং ভিডিওগুলিতে পূর্ণ যেখানে তাদের লেখকরা এই বছরের ফ্ল্যাগশিপ স্মার্টফোনগুলির প্রশংসা করেছেন যেগুলিতে 16-কোর প্রসেসর রয়েছে৷ MS Azure একটি 20 কোর প্রসেসর এবং 128 TB RAM সহ একটি ভার্চুয়াল মেশিন প্রদান করে যা $2/ঘন্টারও কম খরচে। দুর্ভাগ্যবশত, থ্রেডের মিথস্ক্রিয়া পরিচালনা করতে সক্ষম না হয়ে সর্বোচ্চটি বের করা এবং এই শক্তিটি ব্যবহার করা অসম্ভব।

পরিভাষা

প্রক্রিয়া - OS অবজেক্ট, বিচ্ছিন্ন ঠিকানা স্থান, থ্রেড রয়েছে।
থ্রেড - একটি OS অবজেক্ট, এক্সিকিউশনের ক্ষুদ্রতম একক, একটি প্রক্রিয়ার অংশ, থ্রেডগুলি একটি প্রক্রিয়ার মধ্যে নিজেদের মধ্যে মেমরি এবং অন্যান্য সংস্থান ভাগ করে নেয়।
মাল্টিটাস্কিং - OS সম্পত্তি, একযোগে বেশ কয়েকটি প্রক্রিয়া চালানোর ক্ষমতা
মাল্টি-কোর - প্রসেসরের একটি সম্পত্তি, ডেটা প্রক্রিয়াকরণের জন্য বিভিন্ন কোর ব্যবহার করার ক্ষমতা
মাল্টিপ্রসেসিং - একটি কম্পিউটারের একটি সম্পত্তি, শারীরিকভাবে বিভিন্ন প্রসেসরের সাথে একসাথে কাজ করার ক্ষমতা
মাল্টিথ্রেডিং — একটি প্রক্রিয়ার একটি বৈশিষ্ট্য, বিভিন্ন থ্রেডের মধ্যে ডেটা প্রসেসিং বিতরণ করার ক্ষমতা।
সমান্তরালতা - সময়ের একক প্রতি শারীরিকভাবে একযোগে বেশ কয়েকটি ক্রিয়া সম্পাদন করা
অ্যাসিঙ্ক্রোনি — এই প্রক্রিয়াকরণের সমাপ্তির জন্য অপেক্ষা না করেই একটি অপারেশন সম্পাদন; সম্পাদনের ফলাফল পরে প্রক্রিয়া করা যেতে পারে।

রুপক

সমস্ত সংজ্ঞা ভাল নয় এবং কিছু অতিরিক্ত ব্যাখ্যা প্রয়োজন, তাই আমি আনুষ্ঠানিকভাবে প্রবর্তিত পরিভাষায় প্রাতঃরাশ রান্না সম্পর্কে একটি রূপক যোগ করব। এই রূপকটিতে নাস্তা রান্না করা একটি প্রক্রিয়া।

সকালে নাস্তা তৈরি করার সময় আমি (সিপিইউআমি রান্নাঘরে আসি (কম্পিউটার) আমার 2 হাত আছে (কোর) রান্নাঘরে বেশ কয়েকটি ডিভাইস রয়েছে (IO): চুলা, কেটলি, টোস্টার, রেফ্রিজারেটর। আমি গ্যাস চালু করি, এতে একটি ফ্রাইং প্যান রাখি এবং এটি গরম হওয়ার জন্য অপেক্ষা না করে এতে তেল ঢেলে দিই (অ্যাসিঙ্ক্রোনাসভাবে, নন-ব্লকিং-আইও-ওয়েট), আমি রেফ্রিজারেটর থেকে ডিম বের করে একটি প্লেটে ভেঙ্গে ফেলি, তারপর এক হাত দিয়ে পিটিয়ে ফেলি (থ্রেড # 1), এবং দ্বিতীয় (থ্রেড # 2) প্লেট ধরে রাখা (শেয়ারড রিসোর্স)। এখন আমি কেটলি চালু করতে চাই, কিন্তু আমার যথেষ্ট হাত নেই (থ্রেড অনাহার) এই সময়ে, ফ্রাইং প্যান গরম হয়ে যায় (ফলাফল প্রক্রিয়াকরণ) যাতে আমি যা চাবুক দিয়েছি তা ঢেলে দিই। আমি কেটলির কাছে পৌঁছাই এবং এটি চালু করি এবং বোকার মতো এতে পানি ফুটতে দেখি (ব্লকিং-আইও-ওয়েট), যদিও এই সময়ের মধ্যে তিনি প্লেটটি ধুয়ে ফেলতে পারতেন যেখানে তিনি অমলেটটি চাবুক দিয়েছিলেন।

আমি মাত্র 2 হাত ব্যবহার করে একটি অমলেট রান্না করেছি, এবং আমার কাছে এর বেশি নেই, কিন্তু একই সময়ে, অমলেট চাবুক মারার মুহুর্তে, একবারে 3টি অপারেশন হয়েছিল: অমলেটটি চাবুক মারা, প্লেটটি ধরে রাখা, ফ্রাইং প্যান গরম করা সিপিইউ হল কম্পিউটারের দ্রুততম অংশ, IO হল যা প্রায়শই সবকিছু ধীর হয়ে যায়, তাই প্রায়ই একটি কার্যকর সমাধান হল IO থেকে ডেটা গ্রহণ করার সময় কিছু দিয়ে CPU দখল করা।

রূপক চালিয়ে যাওয়া:

• যদি একটি অমলেট প্রস্তুত করার প্রক্রিয়ার মধ্যে, আমি জামাকাপড় পরিবর্তন করার চেষ্টা করব, এটি মাল্টিটাস্কিংয়ের একটি উদাহরণ হবে। একটি গুরুত্বপূর্ণ সূক্ষ্মতা: কম্পিউটারগুলি মানুষের তুলনায় এতে অনেক ভাল।
• বেশ কয়েকটি শেফ সহ একটি রান্নাঘর, উদাহরণস্বরূপ একটি রেস্টুরেন্টে - একটি মাল্টি-কোর কম্পিউটার।
• অনেক রেস্টুরেন্টে ফুড কোর্টে শপিং সেন্টার-ডাটা সেন্টার

.NET টুলস

.NET অন্যান্য অনেক জিনিসের মতো থ্রেডের সাথে কাজ করতে ভালো। প্রতিটি নতুন সংস্করণের সাথে, এটি তাদের সাথে কাজ করার জন্য আরও বেশি বেশি নতুন সরঞ্জাম, OS থ্রেডগুলির উপর বিমূর্ততার নতুন স্তরগুলি প্রবর্তন করে। বিমূর্ততা নির্মাণের সাথে কাজ করার সময়, ফ্রেমওয়ার্ক বিকাশকারীরা এমন একটি পদ্ধতি ব্যবহার করে যা একটি উচ্চ-স্তরের বিমূর্ততা ব্যবহার করার সময়, এক বা একাধিক স্তরের নীচে যাওয়ার সুযোগ ছেড়ে দেয়। প্রায়শই এটি প্রয়োজনীয় নয়, আসলে এটি একটি শটগান দিয়ে নিজের পায়ে গুলি করার দরজা খুলে দেয়, তবে কখনও কখনও, বিরল ক্ষেত্রে, এটি এমন সমস্যা সমাধানের একমাত্র উপায় হতে পারে যা বর্তমান বিমূর্ততার স্তরে সমাধান করা হয় না। .

টুলস দ্বারা, আমি ফ্রেমওয়ার্ক এবং তৃতীয় পক্ষের প্যাকেজগুলি দ্বারা প্রদত্ত অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস (APIs) এবং সেইসাথে সম্পূর্ণ সফ্টওয়্যার সমাধানগুলিকে বোঝায় যা মাল্টি-থ্রেডেড কোড সম্পর্কিত যেকোনো সমস্যার জন্য অনুসন্ধানকে সহজ করে।

একটি থ্রেড শুরু হচ্ছে

থ্রেড ক্লাস থ্রেড নিয়ে কাজ করার জন্য .NET-এর সবচেয়ে মৌলিক ক্লাস। কনস্ট্রাক্টর দুটি প্রতিনিধিদের মধ্যে একটি গ্রহণ করে:

• থ্রেডস্টার্ট - কোন প্যারামিটার নেই
• ParametrizedThreadStart - টাইপ অবজেক্টের একটি প্যারামিটার সহ।

স্টার্ট মেথড কল করার পর নতুন তৈরি থ্রেডে ডেলিগেট এক্সিকিউট করা হবে। যদি ParametrizedThreadStart ধরনের ডেলিগেট কনস্ট্রাক্টরের কাছে পাঠানো হয়, তাহলে একটা অবজেক্ট স্টার্ট মেথডে পাস করতে হবে। স্ট্রীমে কোনো স্থানীয় তথ্য স্থানান্তর করার জন্য এই প্রক্রিয়াটি প্রয়োজন। এটি লক্ষণীয় যে একটি থ্রেড তৈরি করা একটি ব্যয়বহুল অপারেশন, এবং থ্রেডটি নিজেই একটি ভারী বস্তু, অন্তত কারণ এটি স্ট্যাকের উপর 1MB মেমরি বরাদ্দ করে এবং OS API এর সাথে মিথস্ক্রিয়া প্রয়োজন।

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

ThreadPool ক্লাস একটি পুলের ধারণা উপস্থাপন করে। .NET-এ, থ্রেড পুল হল প্রকৌশলের একটি অংশ, এবং মাইক্রোসফ্টের বিকাশকারীরা বিভিন্ন পরিস্থিতিতে এটি সর্বোত্তমভাবে কাজ করে তা নিশ্চিত করার জন্য অনেক প্রচেষ্টা করেছে৷

সাধারণ ধারণা:

অ্যাপ্লিকেশন শুরু হওয়ার মুহূর্ত থেকে, এটি ব্যাকগ্রাউন্ডে রিজার্ভের মধ্যে বেশ কয়েকটি থ্রেড তৈরি করে এবং সেগুলি ব্যবহারের জন্য নেওয়ার ক্ষমতা প্রদান করে। যদি থ্রেডগুলি ঘন ঘন এবং বড় সংখ্যায় ব্যবহার করা হয়, পুলটি কলারের চাহিদা মেটাতে প্রসারিত হয়। যখন সঠিক সময়ে পুলে কোনো মুক্ত থ্রেড না থাকে, তখন এটি হয় একটি থ্রেড ফিরে আসার জন্য অপেক্ষা করবে, অথবা একটি নতুন তৈরি করবে। এটি অনুসরণ করে যে থ্রেড পুলটি কিছু স্বল্প-মেয়াদী ক্রিয়াকলাপের জন্য দুর্দান্ত এবং অ্যাপ্লিকেশনটির পুরো অপারেশন জুড়ে পরিষেবা হিসাবে চালানো অপারেশনগুলির জন্য খারাপভাবে উপযুক্ত।

পুল থেকে একটি থ্রেড ব্যবহার করার জন্য, একটি QueueUserWorkItem পদ্ধতি রয়েছে যা WaitCallback টাইপের একটি প্রতিনিধিকে গ্রহণ করে, যার 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 এ চালু করা হয়েছিল। এখন এটি অ্যাসিঙ্ক্রোনির সাথে কাজ করার জন্য আদর্শ এবং প্রধান হাতিয়ার। পুরানো পদ্ধতি ব্যবহার করে এমন যেকোনো কোডকে উত্তরাধিকার হিসেবে বিবেচনা করা হয়। TPL এর মৌলিক একক হল System.Threading.Tasks নামস্থান থেকে টাস্ক ক্লাস। একটি কাজ একটি থ্রেড উপর একটি বিমূর্ততা. C# ভাষার নতুন সংস্করণের সাথে, আমরা Tasks - async/await অপারেটরদের সাথে কাজ করার একটি মার্জিত উপায় পেয়েছি। এই ধারণাগুলি অ্যাসিঙ্ক্রোনাস কোড লেখা সম্ভব করেছে যেন এটি সহজ এবং সিঙ্ক্রোনাস ছিল, এটি এমনকি থ্রেডগুলির অভ্যন্তরীণ কাজ সম্পর্কে সামান্য বোঝার অধিকারী ব্যক্তিদের জন্যও এগুলি ব্যবহার করে এমন অ্যাপ্লিকেশনগুলি লেখার জন্য এটি সম্ভব করেছে, দীর্ঘ ক্রিয়াকলাপ সম্পাদন করার সময় যে অ্যাপ্লিকেশনগুলি জমা হয় না। async/await ব্যবহার করা এক বা এমনকি একাধিক নিবন্ধের জন্য একটি বিষয়, তবে আমি কয়েকটি বাক্যে এটির সারাংশ পেতে চেষ্টা করব:

• async হল একটি মেথড রিটার্নিং Task বা void এর একটি সংশোধক
• এবং await হল একটি নন-ব্লকিং টাস্ক ওয়েটিং অপারেটর।

আবারও: ওয়েট অপারেটর, সাধারণ ক্ষেত্রে (ব্যতিক্রম আছে), এক্সিকিউশনের বর্তমান থ্রেডটি আরও রিলিজ করবে, এবং যখন টাস্কটি তার সম্পাদন শেষ করবে, এবং থ্রেডটি (আসলে, প্রসঙ্গটি বলা আরও সঠিক হবে) , কিন্তু পরে আরও) পদ্ধতিটি আরও কার্যকর করা চালিয়ে যাবে। .NET-এর অভ্যন্তরে, এই পদ্ধতিটি ফলন রিটার্নের মতোই প্রয়োগ করা হয়, যখন লিখিত পদ্ধতিটি একটি সম্পূর্ণ শ্রেণিতে পরিণত হয়, যা একটি রাষ্ট্রীয় যন্ত্র এবং এই রাজ্যগুলির উপর নির্ভর করে পৃথক টুকরোতে কার্যকর করা যেতে পারে। আগ্রহী যে কেউ asynс/await ব্যবহার করে যেকোন সাধারণ কোড লিখতে পারেন, কম্পাইলার জেনারেটেড কোড সক্ষম করে JetBrains ডটপিক ব্যবহার করে সমাবেশটি কম্পাইল করতে এবং দেখতে পারেন।

আসুন টাস্ক চালু এবং ব্যবহার করার বিকল্পগুলি দেখি। নীচের কোড উদাহরণে, আমরা একটি নতুন টাস্ক তৈরি করি যা কিছু কার্যকর করে না (থ্রেড।স্লিপ(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। একটি অপারেশন শুরু হওয়ার পরে বাতিলকরণ সঠিকভাবে পরিচালনা করার জন্য, কার্যকর করা কোডটি অবশ্যই বাতিলকরণ টোকেন অবস্থার জন্য চেক দিয়ে পূরণ করতে হবে। যদি কোন চেক না থাকে, তাহলে ক্যানসেলেশন টোকেনসোর্স অবজেক্টে বলা বাতিল পদ্ধতিটি টাস্কটি শুরু হওয়ার আগে এটি কার্যকর করা বন্ধ করতে সক্ষম হবে।

শেষ পরামিতি হল 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
}

প্রথম উদাহরণে, আমরা কলিং থ্রেড ব্লক না করে টাস্কটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করি; আমরা ফলাফলটি প্রক্রিয়াকরণে ফিরে আসব যখন এটি ইতিমধ্যেই থাকবে; ততক্ষণ পর্যন্ত, কলিং থ্রেডটি তার নিজস্ব ডিভাইসে রেখে দেওয়া হয়।

দ্বিতীয় বিকল্পে, পদ্ধতির ফলাফল গণনা না হওয়া পর্যন্ত আমরা কলিং থ্রেডটি ব্লক করি। এটি কেবলমাত্র এই কারণেই খারাপ নয় যে আমরা একটি থ্রেড দখল করেছি, প্রোগ্রামের এমন একটি মূল্যবান সংস্থান, সহজ অলসতার সাথে, তবে এটিও কারণ যদি আমরা যে পদ্ধতিটি কল করি তার কোডটি অপেক্ষা করে এবং সিঙ্ক্রোনাইজেশন প্রেক্ষাপটের পরে কলিং থ্রেডে ফিরে আসা প্রয়োজন। অপেক্ষা করুন, তারপরে আমরা একটি অচলাবস্থা পাব : কলিং থ্রেডটি গণনা করার জন্য অ্যাসিঙ্ক্রোনাস পদ্ধতির ফলাফলের জন্য অপেক্ষা করে, অ্যাসিঙ্ক্রোনাস পদ্ধতিটি কলিং থ্রেডে তার সম্পাদন চালিয়ে যাওয়ার জন্য বৃথা চেষ্টা করে।

এই পদ্ধতির আরেকটি অসুবিধা হল জটিল ত্রুটি পরিচালনা। আসল বিষয়টি হ'ল অ্যাসিঙ্ক্রোনাস কোডের ত্রুটিগুলি অ্যাসিঙ্ক/ওয়েট ব্যবহার করার সময় পরিচালনা করা খুব সহজ - তারা একই আচরণ করে যেন কোডটি সিঙ্ক্রোনাস ছিল। আমরা যদি একটি টাস্কে সিঙ্ক্রোনাস ওয়েট এক্সোসসিজম প্রয়োগ করি, তবে আসল ব্যতিক্রমটি সামগ্রিক ব্যতিক্রমে পরিণত হয়, যেমন ব্যতিক্রমটি পরিচালনা করতে, আপনাকে InnerException প্রকারটি পরীক্ষা করতে হবে এবং C# বিশ্বে বেশি পরিচিত ক্যাচ ব্লকের চেইনের পরিবর্তে একটি ক্যাচ ব্লকের ভিতরে একটি if চেইন লিখতে হবে বা নির্মাণের সময় ক্যাচটি ব্যবহার করতে হবে।

তৃতীয় এবং চূড়ান্ত উদাহরণগুলিও একই কারণে খারাপ হিসাবে চিহ্নিত করা হয়েছে এবং একই সমস্যা রয়েছে।

WhenAny এবং WhenAll পদ্ধতিগুলি কাজগুলির একটি গোষ্ঠীর জন্য অপেক্ষা করার জন্য অত্যন্ত সুবিধাজনক; তারা কার্যগুলির একটি গোষ্ঠীকে একটিতে মোড়ানো হয়, যেটি হয় যখন গ্রুপ থেকে একটি টাস্ক প্রথম ট্রিগার করা হয়, বা যখন তাদের সবগুলি তাদের সম্পাদন করা হয় তখন ফায়ার হবে৷

থ্রেড থামানো

বিভিন্ন কারণে, এটি শুরু হওয়ার পরে প্রবাহ বন্ধ করার প্রয়োজন হতে পারে। এটি করার জন্য বেশ কয়েকটি উপায় রয়েছে। থ্রেড ক্লাসে দুটি যথাযথভাবে নামকরণ করা পদ্ধতি রয়েছে: বাতিল и বাধা দেয়. প্রথম একটি অত্যন্ত ব্যবহারের জন্য সুপারিশ করা হয় না, কারণ যেকোন এলোমেলো মুহুর্তে এটি কল করার পরে, কোন নির্দেশের প্রক্রিয়াকরণের সময়, একটি ব্যতিক্রম নিক্ষেপ করা হবে ThreadAbortedException. কোনো পূর্ণসংখ্যা ভেরিয়েবল বৃদ্ধি করার সময় আপনি এই ধরনের ব্যতিক্রম আশা করেন না, তাই না? এবং এই পদ্ধতি ব্যবহার করার সময়, এটি একটি খুব বাস্তব পরিস্থিতি। আপনি যদি CLR-কে কোডের একটি নির্দিষ্ট বিভাগে এমন একটি ব্যতিক্রম তৈরি করা থেকে আটকাতে চান, তাহলে আপনি এটিকে কলগুলিতে মোড়ানো করতে পারেন থ্রেড। শুরু সমালোচনামূলক অঞ্চল, Thread.EndCriticalRegion. একটি চূড়ান্ত ব্লকে লেখা যেকোনো কোড এই ধরনের কলগুলিতে মোড়ানো হয়। এই কারণে, ফ্রেমওয়ার্ক কোডের গভীরতায় আপনি খালি চেষ্টা করে ব্লকগুলি খুঁজে পেতে পারেন, তবে শেষ পর্যন্ত খালি নয়। মাইক্রোসফ্ট এই পদ্ধতিটিকে এতটাই নিরুৎসাহিত করে যে তারা এটিকে .net কোরে অন্তর্ভুক্ত করেনি।

বিঘ্নিত পদ্ধতি আরো অনুমানযোগ্যভাবে কাজ করে। এটি একটি ব্যতিক্রম সঙ্গে থ্রেড বাধা দিতে পারে ThreadInterruptedException শুধুমাত্র সেই মুহুর্তগুলির সময় যখন থ্রেডটি অপেক্ষারত অবস্থায় থাকে। WaitHandle, লক, বা Thread.Sleep কল করার পরে অপেক্ষা করার সময় এটি ঝুলন্ত অবস্থায় এই অবস্থায় প্রবেশ করে।

উপরে বর্ণিত উভয় বিকল্পই তাদের অনির্দেশ্যতার কারণে খারাপ। সমাধান একটি কাঠামো ব্যবহার করা হয় বাতিলকরণ টোকেন এবং ক্লাস বাতিলকরণ টোকেন উৎস. মূল বিষয় হল: CancelationTokenSource ক্লাসের একটি উদাহরণ তৈরি করা হয়েছে এবং শুধুমাত্র যিনি এটির মালিক তিনি পদ্ধতিটিকে কল করে অপারেশন বন্ধ করতে পারেন বাতিল. শুধুমাত্র ক্যান্সেলেশন টোকেনই অপারেশনে পাস করা হয়। বাতিলকরণ টোকেনের মালিকরা নিজেরা অপারেশনটি বাতিল করতে পারে না, তবে শুধুমাত্র অপারেশনটি বাতিল করা হয়েছে কিনা তা পরীক্ষা করতে পারে। এই জন্য একটি বুলিয়ান সম্পত্তি আছে বাতিল করার অনুরোধ করা হয়েছে এবং পদ্ধতি ThrowIfCancelRequested. পরেরটি একটি ব্যতিক্রম নিক্ষেপ করবে TaskCancelledException যদি ক্যানসেলেশন টোকেন ইন্সট্যান্স প্যারোটেডের উপর বাতিল পদ্ধতি কল করা হয়। এবং এই পদ্ধতিটি আমি ব্যবহার করার পরামর্শ দিই। কোন সময়ে একটি ব্যতিক্রম অপারেশন বাতিল করা যেতে পারে তার উপর সম্পূর্ণ নিয়ন্ত্রণ লাভ করে এটি পূর্ববর্তী বিকল্পগুলির তুলনায় একটি উন্নতি।

একটি থ্রেড বন্ধ করার জন্য সবচেয়ে নৃশংস বিকল্প হল Win32 API TerminateThread ফাংশন কল করা। এই ফাংশনটি কল করার পরে CLR-এর আচরণ অনির্দেশ্য হতে পারে। MSDN এ এই ফাংশন সম্পর্কে নিম্নলিখিত লেখা আছে: "TerminateThread একটি বিপজ্জনক ফাংশন যা শুধুমাত্র সবচেয়ে চরম ক্ষেত্রে ব্যবহার করা উচিত। "

FromAsync পদ্ধতি ব্যবহার করে লিগ্যাসি APIকে টাস্ক ভিত্তিক রূপান্তর করা হচ্ছে

আপনি যদি এমন একটি প্রকল্পে কাজ করার জন্য যথেষ্ট ভাগ্যবান হন যা টাস্ক চালু হওয়ার পরে শুরু হয়েছিল এবং বেশিরভাগ ডেভেলপারদের জন্য শান্ত আতঙ্কের কারণ হয়ে দাঁড়িয়েছে, তাহলে আপনাকে অনেকগুলি পুরানো API-এর সাথে মোকাবিলা করতে হবে না, উভয় তৃতীয় পক্ষ এবং আপনার দল অতীতে নির্যাতন করেছে। ভাগ্যক্রমে, .NET ফ্রেমওয়ার্ক টিম আমাদের যত্ন নিয়েছে, যদিও সম্ভবত লক্ষ্য ছিল নিজেদের যত্ন নেওয়া। সেটা যেমনই হোক না কেন, .NET-এর কাছে পুরনো অ্যাসিঙ্ক্রোনাস প্রোগ্রামিং পদ্ধতিতে লিখিত কোডকে নতুনের সাথে যন্ত্রণাহীনভাবে রূপান্তর করার জন্য বেশ কিছু টুল রয়েছে। তার মধ্যে একটি হল টাস্কফ্যাক্টরির FromAsync পদ্ধতি। নীচের কোড উদাহরণে, আমি এই পদ্ধতি ব্যবহার করে একটি টাস্কে WebRequest ক্লাসের পুরানো অ্যাসিঙ্ক পদ্ধতিগুলি মোড়ানো।

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

এটি শুধুমাত্র একটি উদাহরণ এবং আপনাকে অন্তর্নির্মিত প্রকারের সাথে এটি করার সম্ভাবনা নেই, তবে যেকোন পুরানো প্রকল্পটি কেবল BeginDoSomething পদ্ধতির সাথে মিলিত হয় যা এটি প্রাপ্ত IAsyncResult এবং EndDoSomething পদ্ধতিগুলি ফিরিয়ে দেয়।

TaskCompletionSource ক্লাস ব্যবহার করে Legacy API কে Task-ভিত্তিক রূপান্তর করুন

বিবেচনা করার আরেকটি গুরুত্বপূর্ণ হাতিয়ার হল ক্লাস টাস্ক কমপ্লিশন সোর্স. ফাংশন, উদ্দেশ্য এবং অপারেশনের নীতির পরিপ্রেক্ষিতে, এটি থ্রেডপুল ক্লাসের RegisterWaitForSingleObject পদ্ধতির কিছুটা স্মরণ করিয়ে দিতে পারে, যা আমি উপরে লিখেছি। এই ক্লাসটি ব্যবহার করে, আপনি সহজেই এবং সুবিধাজনকভাবে টাস্কগুলিতে পুরানো অ্যাসিঙ্ক্রোনাস APIগুলিকে মোড়ানো করতে পারেন৷

আপনি বলবেন যে আমি ইতিমধ্যে এই উদ্দেশ্যে টাস্কফ্যাক্টরি ক্লাসের FromAsync পদ্ধতি সম্পর্কে কথা বলেছি। এখানে আমাদের মনে রাখতে হবে .net-এ অ্যাসিঙ্ক্রোনাস মডেলগুলির বিকাশের সম্পূর্ণ ইতিহাস যা মাইক্রোসফ্ট গত 15 বছরে অফার করেছে: টাস্ক-ভিত্তিক অ্যাসিঙ্ক্রোনাস প্যাটার্ন (TAP) এর আগে, অ্যাসিঙ্ক্রোনাস প্রোগ্রামিং প্যাটার্ন (APP), যা ছিল। পদ্ধতি সম্পর্কে ছিল শুরু করাকিছু ফিরে আসছে IAsyncResult এবং পদ্ধতি শেষDoSomething যা এটি গ্রহণ করে এবং এই বছরের উত্তরাধিকারের জন্য FromAsync পদ্ধতিটি একেবারে নিখুঁত, কিন্তু সময়ের সাথে সাথে, এটি ইভেন্ট ভিত্তিক অ্যাসিঙ্ক্রোনাস প্যাটার্ন দ্বারা প্রতিস্থাপিত হয়েছিল (ইএপি), যা ধরে নিয়েছিল যে অ্যাসিঙ্ক্রোনাস অপারেশন সম্পন্ন হলে একটি ইভেন্ট উত্থাপিত হবে।

TaskCompletionSource ইভেন্ট মডেলের চারপাশে তৈরি টাস্ক এবং লিগ্যাসি API গুলি মোড়ানোর জন্য উপযুক্ত। এর কাজের সারমর্মটি নিম্নরূপ: এই শ্রেণীর একটি অবজেক্টের একটি পাবলিক প্রপার্টি রয়েছে টাস্ক টাইপের, যার অবস্থা টাস্ককমপ্লিশন সোর্স ক্লাসের SetResult, SetException ইত্যাদি পদ্ধতির মাধ্যমে নিয়ন্ত্রণ করা যেতে পারে। যেখানে এই টাস্কে ওয়েট অপারেটর প্রয়োগ করা হয়েছে, সেখানে টাস্ককমপ্লিশন সোর্সে প্রয়োগ করা পদ্ধতির উপর নির্ভর করে এটি কার্যকর করা হবে বা ব্যতিক্রম সহ ব্যর্থ হবে। যদি এটি এখনও পরিষ্কার না হয়, তাহলে আসুন এই কোডের উদাহরণটি দেখি, যেখানে কিছু পুরানো EAP API টাস্ক কমপ্লিশন সোর্স ব্যবহার করে একটি টাস্কে মোড়ানো হয়: যখন ইভেন্ট ফায়ার হয়, টাস্কটি সম্পূর্ণ অবস্থায় স্থাপন করা হবে এবং যে পদ্ধতিটি অপেক্ষা অপারেটরকে প্রয়োগ করে এই টাস্কটি অবজেক্টটি পাওয়ার পরে এটির সম্পাদন পুনরায় শুরু করবে ফল.

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

টাস্ক কমপ্লিশন সোর্স টিপস এবং ট্রিকস

পুরানো 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# সিনট্যাক্স দৃষ্টিকোণ থেকে, এই ক্ষেত্রে একটি নিয়মিত টাস্কের মতোই আচরণ করবে৷

টাস্ক শিডিউলার: টাস্ক লঞ্চ কৌশল পরিচালনা করা

পরবর্তী API যা আমি বিবেচনা করতে চাই তা হল ক্লাস কাজের সূচি এবং এর ডেরিভেটিভস। আমি ইতিমধ্যে উপরে উল্লেখ করেছি যে TPL থ্রেড জুড়ে টাস্ক বিতরণের জন্য কৌশলগুলি পরিচালনা করার ক্ষমতা রাখে। এই ধরনের কৌশলগুলি TaskScheduler শ্রেণীর বংশধরদের মধ্যে সংজ্ঞায়িত করা হয়। আপনার প্রয়োজন হতে পারে প্রায় যেকোনো কৌশল লাইব্রেরিতে পাওয়া যাবে। সমান্তরাল এক্সটেনশন এক্সট্রা, মাইক্রোসফ্ট দ্বারা বিকশিত, কিন্তু .NET এর অংশ নয়, কিন্তু একটি Nuget প্যাকেজ হিসাবে সরবরাহ করা হয়েছে৷ আসুন সংক্ষেপে তাদের কয়েকটি দেখি:

• CurrentThreadTaskScheduler — বর্তমান থ্রেডে কার্য সম্পাদন করে
• Limited Concurrency LevelTask ​​Scheduler — পরামিতি N দ্বারা একযোগে সম্পাদিত কার্যের সংখ্যা সীমিত করে, যা কনস্ট্রাক্টরে গৃহীত হয়
• অর্ডার করা টাস্ক শিডিউলার —কে LimitedConcurrencyLevelTaskScheduler(1) হিসাবে সংজ্ঞায়িত করা হয়েছে, তাই কাজগুলি ক্রমানুসারে কার্যকর করা হবে।
• WorkStealingTaskScheduler - প্রয়োগ করে কাজ চুরি টাস্ক বিতরণের পদ্ধতি। মূলত এটি একটি পৃথক থ্রেডপুল। সমস্যাটি সমাধান করে যে .NET থ্রেডপুল একটি স্ট্যাটিক ক্লাস, সমস্ত অ্যাপ্লিকেশনের জন্য একটি, যার অর্থ হল প্রোগ্রামের একটি অংশে এটির ওভারলোডিং বা ভুল ব্যবহার অন্যটিতে পার্শ্ব প্রতিক্রিয়া সৃষ্টি করতে পারে। তাছাড়া, এই ধরনের ত্রুটির কারণ বোঝা অত্যন্ত কঠিন। যে. প্রোগ্রামের কিছু অংশে আলাদা WorkStealingTaskSchedulers ব্যবহার করার প্রয়োজন হতে পারে যেখানে ThreadPool ব্যবহার আক্রমণাত্মক এবং অপ্রত্যাশিত হতে পারে।
• সারিবদ্ধ টাস্ক শিডিউলার — আপনাকে অগ্রাধিকার সারির নিয়ম অনুযায়ী কাজ সম্পাদন করতে দেয়
• ThreadPerTaskScheduler — এটিতে সম্পাদিত প্রতিটি টাস্কের জন্য একটি পৃথক থ্রেড তৈরি করে। এমন কাজগুলির জন্য দরকারী হতে পারে যেগুলি সম্পূর্ণ হতে অপ্রত্যাশিতভাবে দীর্ঘ সময় নেয়।

একটি ভাল বিস্তারিত আছে একটি নিবন্ধ মাইক্রোসফ্ট ব্লগে টাস্কশিডিউলার সম্পর্কে।

টাস্কের সাথে সম্পর্কিত সবকিছুর সুবিধাজনক ডিবাগিংয়ের জন্য, ভিজ্যুয়াল স্টুডিওতে একটি টাস্ক উইন্ডো রয়েছে। এই উইন্ডোতে আপনি টাস্কের বর্তমান অবস্থা দেখতে পারেন এবং কোডের বর্তমানে এক্সিকিউটিং লাইনে যেতে পারেন।

PLinq এবং সমান্তরাল শ্রেণী

টাস্ক এবং সেগুলি সম্পর্কে বলা সমস্ত কিছু ছাড়াও, .NET-এ আরও দুটি আকর্ষণীয় টুল রয়েছে: PLinq (Linq2Parallel) এবং সমান্তরাল ক্লাস। প্রথমটি একাধিক থ্রেডে সমস্ত Linq অপারেশনগুলির সমান্তরাল সম্পাদনের প্রতিশ্রুতি দেয়। WithDegreeOfParallelism এক্সটেনশন পদ্ধতি ব্যবহার করে থ্রেডের সংখ্যা কনফিগার করা যেতে পারে। দুর্ভাগ্যবশত, প্রায়শই PLinq এর ডিফল্ট মোডে আপনার ডেটা উৎসের অভ্যন্তরীণ সম্পর্কে যথেষ্ট তথ্য থাকে না যাতে একটি উল্লেখযোগ্য গতি লাভ করা যায়, অন্যদিকে, চেষ্টা করার খরচ খুবই কম: আপনাকে আগে AsParallel পদ্ধতিতে কল করতে হবে Linq পদ্ধতির চেইন এবং কর্মক্ষমতা পরীক্ষা চালায়। তাছাড়া, পার্টিশন মেকানিজম ব্যবহার করে আপনার ডেটা উৎসের প্রকৃতি সম্পর্কে PLinq-কে অতিরিক্ত তথ্য পাঠানো সম্ভব। আপনি আরো পড়তে পারেন এখানে и এখানে.

সমান্তরাল স্ট্যাটিক ক্লাস সমান্তরালভাবে একটি Foreach সংগ্রহের মাধ্যমে পুনরাবৃত্তি করার পদ্ধতি প্রদান করে, একটি ফর লুপ চালানো এবং সমান্তরাল ইনভোকে একাধিক প্রতিনিধি কার্যকর করা। গণনা সম্পূর্ণ না হওয়া পর্যন্ত বর্তমান থ্রেডের সম্পাদন বন্ধ করা হবে। শেষ আর্গুমেন্ট হিসাবে ParallelOptions পাস করে থ্রেডের সংখ্যা কনফিগার করা যেতে পারে। আপনি বিকল্পগুলি ব্যবহার করে TaskScheduler এবং CancellationTokenও নির্দিষ্ট করতে পারেন।

তথ্যও

আমি যখন আমার প্রতিবেদনের উপকরণ এবং এর পরে আমার কাজের সময় যে তথ্য সংগ্রহ করেছি তার উপর ভিত্তি করে এই নিবন্ধটি লেখা শুরু করি, তখন আমি আশা করিনি যে এটি এত বেশি হবে। এখন, যখন টেক্সট এডিটর যেখানে আমি এই নিবন্ধটি টাইপ করছি সে আমাকে নিন্দিতভাবে বলে যে পৃষ্ঠা 15 চলে গেছে, আমি অন্তর্বর্তী ফলাফলগুলি সংক্ষিপ্ত করব। অন্যান্য কৌশল, এপিআই, ভিজ্যুয়াল টুল এবং ত্রুটিগুলি পরবর্তী নিবন্ধে কভার করা হবে।

সিদ্ধান্তে:

• আধুনিক পিসিগুলির সংস্থানগুলি ব্যবহার করার জন্য আপনাকে থ্রেড, অ্যাসিঙ্ক্রোনি এবং সমান্তরালতার সাথে কাজ করার জন্য সরঞ্জামগুলি জানতে হবে।
• এই উদ্দেশ্যে .NET এর অনেকগুলি বিভিন্ন সরঞ্জাম রয়েছে
• এগুলি সবগুলি একবারে উপস্থিত হয়নি, তাই আপনি প্রায়শই উত্তরাধিকারগুলি খুঁজে পেতে পারেন, তবে, অনেক প্রচেষ্টা ছাড়াই পুরানো APIগুলি রূপান্তর করার উপায় রয়েছে৷
• .NET-এ থ্রেডের সাথে কাজ করা থ্রেড এবং থ্রেডপুল ক্লাস দ্বারা প্রতিনিধিত্ব করা হয়
• Thread.Abort, Thread.Interrupt, এবং Win32 API TerminateThread পদ্ধতি বিপজ্জনক এবং ব্যবহারের জন্য সুপারিশ করা হয় না। পরিবর্তে, বাতিলকরণ টোকেন পদ্ধতি ব্যবহার করা ভাল
• প্রবাহ একটি মূল্যবান সম্পদ এবং এর সরবরাহ সীমিত। থ্রেডগুলি ইভেন্টের জন্য অপেক্ষায় ব্যস্ত থাকে এমন পরিস্থিতি এড়ানো উচিত। এর জন্য TaskCompletionSource ক্লাস ব্যবহার করা সুবিধাজনক
• সমান্তরালতা এবং অ্যাসিঙ্ক্রোনির সাথে কাজ করার জন্য সবচেয়ে শক্তিশালী এবং উন্নত .NET টুল হল টাস্ক।
• c# async/await অপারেটররা নন-ব্লকিং অপেক্ষার ধারণাটি বাস্তবায়ন করে
• আপনি TaskScheduler-প্রাপ্ত ক্লাস ব্যবহার করে থ্রেড জুড়ে টাস্কের বিতরণ নিয়ন্ত্রণ করতে পারেন
• ভ্যালুটাস্ক কাঠামো হট-পাথ এবং মেমরি-ট্র্যাফিক অপ্টিমাইজ করতে কার্যকর হতে পারে
• ভিজ্যুয়াল স্টুডিওর টাস্ক এবং থ্রেড উইন্ডোগুলি মাল্টি-থ্রেডেড বা অ্যাসিঙ্ক্রোনাস কোড ডিবাগ করার জন্য দরকারী অনেক তথ্য সরবরাহ করে
• PLinq একটি দুর্দান্ত সরঞ্জাম, তবে এটিতে আপনার ডেটা উত্স সম্পর্কে পর্যাপ্ত তথ্য নাও থাকতে পারে, তবে এটি পার্টিশন প্রক্রিয়া ব্যবহার করে ঠিক করা যেতে পারে
• চলবে…

উত্স: www.habr.com