কেন আমাদের অ্যাসিঙ্ক কীওয়ার্ডের প্রয়োজন?


19

আমি সবেমাত্র async দিয়ে খেলা শুরু করেছি / নেট। 4.5। আমি প্রথমে একটি বিষয় সম্পর্কে কৌতূহলী, কেন অ্যাসিঙ্ক কীওয়ার্ডটি প্রয়োজনীয়? আমি যে ব্যাখ্যাটি পড়েছি তা হ'ল এটি একটি চিহ্নিতকারী তাই সংকলকটি জানে যে কোনও পদ্ধতি কোনও কিছুর জন্য অপেক্ষা করছে। তবে মনে হয় কম্পাইলারটি কোনও কীওয়ার্ড ছাড়াই এটি বের করতে সক্ষম হবে। সুতরাং এটি আর কি করে?


2
এখানে একটি দুর্দান্ত ব্লগ নিবন্ধ (সিরিজ) রয়েছে যা C # তে কীওয়ার্ড এবং এফ # তে সম্পর্কিত কার্যকারিতা বর্ণনা করার কিছু বিশদে চলে গেছে।
পল

আমি মনে করি এটি মূলত বিকাশকারীদের জন্য চিহ্নিতকারী, এবং সংকলকটির জন্য নয়।
কোডসইনচাউস

8
এই নিবন্ধটি এটি ব্যাখ্যা করেছে: ব্লগস.এমএসডিএন
বি

@ এসভিক ধন্যবাদ, আমি এটিই খুঁজছিলাম এখন নিখুঁত জ্ঞান তোলে।
কন্ডিশন

উত্তর:


23

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

এটি "সংস্থাপককে বিশেষ পদ্ধতিতে ফাংশনটি রূপান্তরিত করার জন্য নির্দেশনা দেওয়ার নয়"; awaitএকা এটি করতে পারে কেন? সি শার্প ইতিমধ্যেই অন্য প্রক্রিয়া যেখানে পদ্ধতি শরীরের একটি বিশেষ শব্দ উপস্থিতিতে চরম (এবং খুব অনুরূপ সম্পাদন করতে কম্পাইলার কারণ হয়েছে কারন async/awaitপদ্ধতি শরীরের উপর) রূপান্তরের: yield

ছাড়া যে yieldসি # তার নিজস্ব শব্দ নয়, এবং কেন সেই ব্যাপারটি বুঝা ব্যাখ্যা করবে asyncপাশাপাশি। এই মেকানিজমকে সমর্থন করে এমন বেশিরভাগ ভাষার মতো নয়, সি # তে আপনি বলতে পারবেন না পরিবর্তে yield value;আপনাকে বলতে yield return value;হবে। কেন? কারণ এটি সি # ইতিমধ্যে বিদ্যমান থাকার পরে ভাষায় যুক্ত হয়েছিল এবং এটি ধরে নেওয়া বেশ যুক্তিসঙ্গত ছিল যে কেউ, কোথাও কেউ yieldভেরিয়েবলের নাম হিসাবে ব্যবহার করেছে। তবে যে প্রাক-বিদ্যমান পরিস্থিতিটি <variable name> returnছিল না যেখানে সিনট্যাক্টিকভাবে সঠিক ছিল, yield returnভাষাতে যুক্ত হয়েছে জেনারেটরগুলি প্রবর্তন করা সম্ভব করার সাথে সাথে বিদ্যমান কোডের সাথে 100% পিছনের সামঞ্জস্য বজায় রাখা সম্ভব হয়েছিল।

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


3
এই নিবন্ধটি যা বলেছে তা এটি বেশ সুন্দর (মূলত মন্তব্যগুলিতে @ স্পাইক দ্বারা পোস্ট করা) তবে এর উত্তর হিসাবে কেউ পোস্ট করেনি। মাত্র আড়াই বছর লেগেছিল! ধন্যবাদ :)
কন্ডিশন

এর অর্থ এই নয় যে কোনও ভবিষ্যতের সংস্করণে asyncকীওয়ার্ড নির্দিষ্ট করার প্রয়োজনীয়তা বাদ দেওয়া যেতে পারে? স্পষ্টতই এটি একটি বিসি বিরতি হবে তবে এটি খুব কম প্রকল্পগুলিকে প্রভাবিত করবে এবং আপগ্রেড করার জন্য (যেমন একটি ভেরিয়েবলের নাম পরিবর্তন করা) একটি সোজা-সামনের প্রয়োজন হতে পারে বলে মনে করা যেতে পারে।
কোলোনেল প্রশ্ন

6

এটি একটি সাধারণ পদ্ধতি থেকে কলব্যাক সহ কোনও অবজেক্টে পদ্ধতি পরিবর্তন করে যার কোড উত্পন্ন করার জন্য একেবারে পৃথক পদ্ধতির প্রয়োজন

এবং যখন এরকম কঠোর কিছু ঘটে তখন এটি স্পষ্টভাবে বোঝানোর প্রথাগত হয় (আমরা সেই পাঠটি সি ++ থেকে শিখেছি)


সুতরাং এটি পাঠক / প্রোগ্রামারটির জন্য সত্যিই কিছু এবং সংকলকের জন্য এতটা না?
কন্ডিশন

@ জাস্টিন ৯৮৪ এটি অবশ্যই সংঘটিত হওয়ার জন্য বিশেষ কিছু ঘটতে হবে বলে সংকেত দিতে সহায়তা করে
র‌্যাচেট ফ্রিক

আমি অনুমান করি যে আমি কৌতূহলী কেন সংকলকটির এটির প্রয়োজন। এটি কি কেবল পদ্ধতিটি বিশ্লেষণ করে দেখতে পেল না যে অপেক্ষা করার পদ্ধতিটি কোথাও রয়েছে?
কন্ডিশন

আপনি যখন asyncএকই সাথে একাধিক গুলি নির্ধারণ করতে চান এটি সহায়তা করে যাতে তারা একের পর এক চলতে না পারে তবে একই সাথে (যদি থ্রেডগুলি অন্তত উপলব্ধ থাকে)
ratchet freak

@ জাস্টিন 84৮৪: প্রত্যাবর্তিত প্রতিটি পদ্ধতির Task<T>আসলে কোনও asyncপদ্ধতির বৈশিষ্ট্য থাকে না - উদাহরণস্বরূপ, আপনি কেবল কিছু ব্যবসা / কারখানার যুক্তি দিয়ে চলতে পারেন এবং তারপরে ফিরে আসা অন্য কোনও পদ্ধতিতে প্রতিনিধি অর্পণ করতে পারেন Task<T>asyncপদ্ধতি রিটার্ন টাইপ আছে Task<T>মধ্যে স্বাক্ষর কিন্তু না আসলে একটি ফিরতি Task<T>, তারা শুধু একটি ফিরতি Tasyncকীওয়ার্ড ব্যতীত এগুলির সমস্ত কিছু বের করার জন্য , সি # সংকলকটিকে পদ্ধতির সমস্ত ধরণের গভীর পরিদর্শন করতে হবে, যা সম্ভবত এটি কিছুটা ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে পড়ে না।
অ্যারোনআউট

4

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


আমি ডাউনভোট করতে প্রলুব্ধ হলাম কারণ প্রথম অনুচ্ছেদটি সঠিক হওয়ার সাথে সাথে বাধাগুলির সাথে তুলনাটি ভুল (আমার জ্ঞাত মতামত)।
পল

আমি এগুলিকে উদ্দেশ্যগত দিক থেকে কিছুটা উপমা হিসাবে দেখছি তবে আমি স্পষ্টতার জন্য এটিকে সরিয়ে দেব।
বিশ্ব প্রকৌশলী

বাধাগুলি আমার মতে অ্যাসিঙ্ক কোডের চেয়ে ইভেন্টের মতো - এটি স্বাভাবিক কোড পুনরায় শুরু হওয়ার আগেই প্রসঙ্গের স্যুইচ করে এবং সমাপ্তির দিকে চালিত হয় (এবং সাধারণ কোডটি এটি চলমান সম্পর্কেও পুরোপুরি অজ্ঞ থাকে), তবে অ্যাসিঙ্ক কোডের সাহায্যে পদ্ধতিটি সম্ভবত কলিং থ্রেড আবার শুরু হওয়ার আগে শেষ হয়নি। আমি দেখতে পাচ্ছি যে আপনি হুড়ির নীচে বিভিন্ন বাস্তবায়নের জন্য বিভিন্ন প্রক্রিয়া বলার চেষ্টা করছেন, কিন্তু বাধা আমার সাথে এই বিষয়টিকে চিত্রিত করার জন্য জিব করে নি। (বাকিদের জন্য +1, বিটিডাব্লু।)
পল

0

ঠিক আছে, এটি আমার গ্রহণ এখানে।

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

সি ম্যাক্রোগুলির সাথে প্রয়োগ করার জন্য তারা সহজেই সহজ, যেমন "প্রোটোথ্রেডস" সম্পর্কে নিম্নলিখিত কাগজে দেখানো হয়েছে। ( http://dunkels.com/adam/dunkels06protothreads.pdf ) এটি পড়ুন। আমি অপেক্ষা করব...

এর নীচের লাইনটি হ'ল ম্যাক্রোগুলি প্রতিটি সাসপেনশন পয়েন্টে একটি বড় switchএবং একটি caseলেবেল তৈরি করে। প্রতিটি সাসপেনশন পয়েন্টে, ফাংশনটি অবিলম্বে নিম্নলিখিত caseলেবেলের মান সঞ্চয় করে , যাতে পরবর্তী সময় যখন ডাকা হয় তখন এটি কার্যকর হয় কোথায় তা জানে। এবং এটি কলারের কাছে নিয়ন্ত্রণ ফিরিয়ে দেয়।

"প্রোটোথ্রেড" বর্ণিত কোডটির আপাত নিয়ন্ত্রণের প্রবাহকে পরিবর্তন না করেই এটি করা হয়।

এখনই কল্পনা করুন যে আপনার কাছে এই সমস্ত "প্রোটোথ্রেডস" পরিবর্তে কল করার একটি বড় লুপ রয়েছে এবং আপনি একই সাথে একক থ্রেডে "প্রোটোথ্রেড" সম্পাদন করতে পারেন।

এই পদ্ধতির দুটি ত্রুটি রয়েছে:

  1. পুনরায় সংস্থানগুলির মধ্যে আপনি স্থানীয় ভেরিয়েবলগুলিতে রাষ্ট্র রাখতে পারবেন না।
  2. আপনি "প্রোটোথ্রেড" স্বেচ্ছাচারিত কল গভীরতা থেকে স্থগিত করতে পারবেন না। (সমস্ত সাসপেনশন পয়েন্টগুলি অবশ্যই 0 স্তরে হওয়া উচিত)

উভয়ের জন্য কর্মক্ষেত্র রয়েছে:

  1. সমস্ত স্থানীয় ভেরিয়েবলগুলি অবশ্যই প্রোটোথ্রিডের প্রসঙ্গে টানা উচিত (প্রসঙ্গটি যা ইতিমধ্যে প্রোটোথ্রেডের পরবর্তী পুনঃস্থাপনের পয়েন্টটি সংরক্ষণ করতে হবে এটি দ্বারা প্রয়োজনীয়)
  2. আপনি যদি মনে করেন যে আপনাকে সত্যিকার অর্থে একটি প্রোটোথ্রেড থেকে অন্য প্রোটোথারথ কল করতে হবে, তবে একটি শিশু প্রোটোথ্রেডকে "স্পন" করতে হবে এবং সন্তানের সমাপ্তি অবধি স্থগিত করা উচিত।

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

এবং এটি যা asyncএবং awaitসমস্ত সম্পর্কে: স্ট্যাকলেস কর্টাইন তৈরি করা।

সি # এর কর্টাইনগুলি (জেনেরিক বা নন-জেনেরিক) শ্রেণীর অবজেক্ট হিসাবে পুনরায় সংশোধন করা হয় Task

আমি এই কীওয়ার্ডগুলি খুব বিভ্রান্তিকর মনে করি। আমার মানসিক পাঠ্য হ'ল:

  • async "সাসপেন্সেবল" হিসাবে
  • await "সম্পূর্ণ না হওয়া পর্যন্ত স্থগিত" হিসাবে
  • Task "ভবিষ্যত ..." হিসাবে

এখন। আমাদের কি সত্যই ফাংশনটি চিহ্নিত করতে হবে async? ফাংশনটিকে কর্টিন বানানোর জন্য কোড পুনর্লিখনের প্রক্রিয়াগুলির ট্রিগার করা উচিত তা বলা ছাড়াও, এটি কিছু অস্পষ্টতাকেও সমাধান করে। এই কোড বিবেচনা করুন।

public Task<object> AmIACoroutine() {
    var tcs = new TaskCompletionSource<object>();
    return tcs.Task;
}

ধরে নেওয়া যে asyncএটি বাধ্যতামূলক নয়, এটি কি কোনও কর্টিন বা একটি সাধারণ ক্রিয়াকলাপ? সংকলকটি কি এটি কর্টিন হিসাবে আবার লিখতে হবে? উভয়ই বিভিন্ন ইভেন্টের শব্দার্থক দ্বারা সম্ভব হতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.