অ্যাসিঙ্ক্রোনাস প্রোগ্রামিং কেবলমাত্র অন্য প্রোগ্রামিং ট্রিকের চেয়ে অনেক বেশি দর্শনের বিষয়। যদিও আপনার শেষ প্রশ্নটি মূলত প্রোগ্রামিংয়ের দিকগুলি সম্পর্কে উত্তরগুলি আকর্ষণ করেছিল এবং আমার উত্তরটি বেশিরভাগ তাত্ত্বিক হওয়ার কারণে একটি সংযোগ বিচ্ছিন্ন দীর্ঘস্থায়ী ছিল, আমি আপনাকে কেবল রেফারেন্সের পরিবর্তে একই লাইনে একটি নতুন দৃষ্টিভঙ্গি বিল্ডিং দেওয়ার চেষ্টা করছি।
এই একটি কেন এবং কীভাবে অ্যাসিনক্রোনাস প্রোগ্রামিংয়ের কয়েকটি মৌলিক বিষয়।
ধরা যাক আপনি একটি বেকারি শপে যান (এবং ধরে নিলেন অর্ডার করার পরে কেক প্রস্তুত হবে) - আপনার দুটি পছন্দ আছে, হয় আপনি কেক প্রস্তুত না হওয়া পর্যন্ত অপেক্ষা করা বেছে নেন বা আপনি অর্ডারটি দিয়ে বাড়ি ফিরে যান এবং বাছাই করেন পরে এটি প্রস্তুত যখন। প্রথমটি (অপেক্ষা) একটি সিঙ্ক্রোনাস পদ্ধতি এবং পরে হ'ল অ্যাসিনক্রোনাস পদ্ধতি । এই উদাহরণটি বলার অপেক্ষা রাখে না যে কেন আপনাকে সিঙ্ক্রোনাসের চেয়ে অ্যাসিক্রোনাস পদ্ধতি ব্যবহার করা উচিত এটি একটি ভাল রেফারেন্স দেয়।
অ্যাসিক্রোনাস সিস্টেমগুলি যেভাবে তৈরি করা যায় তার মধ্যে ইভেন্ট ভিত্তিক প্রোগ্রামিং কেবলমাত্র একটি এবং এটি কেবল একটি দরকারী ডিজাইনের প্যাটার্ন নয় বরং এটি একটি স্থাপত্য নিদর্শন। আমি এমন কেসগুলি তালিকাভুক্ত করছি যেখানে এই তত্ত্বটি ব্যবহারিকভাবে কার্যকর উপায়ে ব্যবহৃত হয় - এই আশা করে যে এটি কিছুটা স্পষ্টতা এনে দেবে
এসিনক্রোনাস সিস্টেমগুলির প্রথম উদাহরণগুলির মধ্যে একটি হ'ল ইউনিক্স সিস্টেম আইও। যদিও আমরা জানি read(), write()এবং এমনকি ব্লকগুলি প্রোগ্রামের প্রবাহকে select()কল করে তবে ওএসের অভ্যন্তরে এগুলি অ্যাসিনক্রোনাস হয়, অর্থাত্ কার্নেল সাধারণত জানে যে ব্লক ডিভাইস (ওরফে হার্ড ডিস্ক) বাফার পূরণ করতে কিছুটা সময় নেবে, যতক্ষণ না সিপিইউ বিনামূল্যে থাকে till সংশ্লিষ্ট থ্রেড থেকে এবং তাই থ্রেডটি পার্ক হিসাবে প্রস্তুত (প্রস্তুত নয়)। পড়ুন 1. মডেম বাখ "ইউনিক্স অপারেটিং সিস্টেমের নকশা"
আর একটি সর্বাধিক সাধারণ উদাহরণ হ'ল সংখ্যাগরিষ্ঠ ইউআই ফ্রেমওয়ার্ক। এখানে, সমস্ত ব্যবহারকারীর ক্লিকগুলি প্রথমে একটি নিয়ামকের মাধ্যমে প্রেরণ করা হয় যার ফলে কলটি সংশ্লিষ্ট অ্যাপ্লিকেশনকে ব্যাক করে। গুরুত্বপূর্ণ বিষয় হ'ল কল ব্যাকগুলিতে কল ব্যাকগুলি অপেক্ষা করা উচিত নয় অন্যথায় সিস্টেম হিমশীতল হয়ে যায়। ভারী প্রক্রিয়াজাতকরণের সাথে জড়িত থাকলে UI নিয়ন্ত্রক থেকে ব্যাক-এন্ডে ফিরে কল সাধারণত অ্যাসিনক্রোনাস হয়।
অ্যাসিক্রোনাস প্রোগ্রামিংয়ের আরও একটি ভাল উদাহরণ (খাঁটি ডিজাইনের ধরণ হিসাবে) অ্যাক্টিভ অবজেক্ট। একটি সক্রিয় অবজেক্ট এমন একটি যা এর নিজস্ব ব্যক্তিগত থ্রেড রয়েছে যাতে যে অনেকগুলি অনুরোধকে একটি কাতারে রাখতে পারে এবং একের পর এক চালিত করতে পারে। এই কাগজটি দেখুন: সক্রিয় বস্তু । এই প্যাটার্নটি সরাসরি এন্টারপ্রাইজ সফ্টওয়্যার থেকে মোবাইল ফ্রেমওয়ার্কগুলিতে ব্যবহার করা হয়। জনপ্রিয় প্ল্যাটফর্মগুলি জাভা / ইজেবি এবং .NET স্থানীয় বা রিমোট অ্যাসিনক্রোনাস পদ্ধতি আমন্ত্রণের অনুমতি দেয় যা মূলত সাধারণ বস্তুগুলিকে সক্রিয় বস্তুতে পরিণত করার অনুমতি দেয়। সিম্বিয়ানে সক্রিয় বস্তুগুলি আবার উপস্থিত ছিল: অপো হ্যাপানেন দ্বারা সিম্বিয়ান ওএসে সক্রিয় বস্তু (এটিও দেখুন: সিম্বিয়ানের সক্রিয় বস্তু )। এটি এখন উপস্থিতঅ্যান্ড্রয়েড )।
অ্যাক্টিভ অবজেক্ট ছাড়াও, একই লেখক ডগলাস সি শ্মিট , এমন আরও অনেক রচনা তৈরি করেছেন যা অ্যাক্টিভ অবজেক্টের অন্যান্য সমান্তরাল এবং অ্যাসিক্রোনাস ধরণও। এই ইভেন্টটি হ্যান্ডলিং প্যাটার্নগুলি দেখুন এবং একটি সম্পূর্ণ অ্যাকাউন্ট তার বই প্যাটার্ন-ওরিয়েন্টেড সফ্টওয়্যার আর্কিটেকচার: কনটেন্ট এবং নেটওয়ার্কওয়াল্ড অবজেক্টগুলির জন্য প্যাটার্নস - ভি 2 এ উপলব্ধ
যখন কোনও প্রদত্ত বস্তুকে এপিআই ফিরিয়ে দেওয়ার দরকার হয়, যখন ব্যাকগ্রাউন্ডে আসলে কাজটি সম্পাদন করার জন্য কাজ করা হয়, তখন সাধারণ পদ্ধতিটি এটি অর্জনের জন্য একটি বহু-থ্রেডযুক্ত সিস্টেম থাকা উচিত। থ্রেডেড সিস্টেমগুলি সি (পিক্সিক্স), সি ++ ( বুস্ট ) থেকে জাভা, সি # ইত্যাদির সর্বত্র উপস্থিত রয়েছে । অ্যাক্টিভ অবজেক্ট মূলত কেবল একটি বিমূর্ততা যা এটি আড়াল করতে পারে। দেখুন কেন সক্রিয় অবজেক্ট বাস্তবায়নের নগ্ন থ্রেড উপর বাঞ্ছনীয় হয়। আরেকটি ভাল পড়া ।
কিন্তু এই ধারণাটি অ্যাসিক্রোনাসে পরিণত হওয়ার জন্য কোনও অ্যাপ্লিকেশনটির ভিতরে থ্রেড বা বস্তু ছাড়িয়ে যায়। সর্বোত্তম ব্যবহারগুলির মধ্যে একটি হ'ল বিতরণকারী সিস্টেমে যেখানে দুটি অ্যাপ্লিকেশন অপরিহার্যভাবে সমন্বয়গুলির জন্য একে অপরের অপেক্ষা করতে হবে না। পুরানো ভাল (বা এত ভাল নয়, আপনি যেদিকেই এটি দেখুন) আরপিসি সিঙ্ক্রোনাস ছিল। [অবশ্যই, অন্যান্য অ্যাসিক্রোনাস আরপিসিও রয়েছে]। তবে মেসেজ ওরিয়েন্টেড মিডলওয়্যারের মতো আধুনিক বিকল্পগুলি ভাল কারণগুলির জন্য সত্যই অবিচ্ছিন্ন।
সর্বশেষ তবে সবচেয়ে আকর্ষণীয় হতে পারে এটি হ'ল এজেন্টস প্রোগ্রামিং যা যোগাযোগের অ্যাসিনক্রোনাস মডেল থেকে উপকৃত হতে পারে ।
যদিও অ্যাসিঙ্ক্রোনাস প্রোগ্রামিংটি সেক্সি দেখায় না তবে এটি তার নিজস্ব জটিলতা তৈরি করে:
- রিটার্ন মান পাসের জন্য কাঠামো
- যোগাযোগের অতিরিক্ত ওভারহেড
- কনস্ট্রাক্টস সিঙ্ক্রোনাইজ করার জন্য অতিরিক্ত প্রয়োজন
- কাজগুলি সঠিকভাবে না করা হলে অচলাবস্থা, রেসিং ইত্যাদির সম্ভাবনা।
... ইত্যাদি।
এটি সর্বদা কেবল আসল কারণে ব্যবহার করা উচিত।
সুতরাং কেউ কখন অ্যাসিক্রোনাস মডেল ব্যবহার করা উচিত? কখন আপনার কোনও পটভূমি থ্রেড রাখা উচিত এবং কলারকে অ্যাসিঙ্ক্রোনাসে যাওয়ার অনুমতি দেওয়া উচিত? এটি প্রয়োগ করার সময় কিছু ভাল থাম্ব বিধি রয়েছে (তবে সম্পূর্ণ নয়)
যখন সিস্টেম কঠোর গুরুতর সংস্থান কথোপকথন প্রয়োগ করতে চায়: উদাহরণস্বরূপ, আপনি থ্রেডের একটি নিখুঁত স্থির সংখ্যা রাখতে চান। অ্যাসিঙ্ক্রোনাস প্যাটার্ন সিস্টেমটিকে সারি প্রয়োগ করতে বাধ্য করে।
কলারের যখন "অন্যান্য দরকারী জিনিসগুলি করতে" করা প্রয়োজন তখন সত্যই। অনেক সময়, অন্য থ্রেডটি অবরোধ মুক্ত করা হলেও, কিছু কার্যকর হবে না এবং ফলাফলের জন্য ভোটদানের চারপাশে ঝুলছে। এটি প্রকৃতপক্ষে বেসিক সিঙ্ক্রোনাস মডেলের চেয়ে বেশি সিপিইউ গ্রহণযোগ্য হতে পারে।
যখন আপনার বিতরণ সিস্টেমে নির্ভরযোগ্যতার উচ্চ স্তরের প্রয়োজন হয়। ( বার্তা ওরিয়েন্টড মিডলওয়্যার দেখুন )।