সমস্ত ফাংশনগুলি ডিফল্টরূপে async হওয়া উচিত নয় কেন?


107

ASYNC-অপেক্ষায় রয়েছেন .net 4.5 এর প্যাটার্ন দৃষ্টান্ত পরিবর্তন নেই। এটি সত্য হতে প্রায় খুব ভাল।

আমি কিছু আইও-ভারী কোড async-প্রতীক্ষায় পোর্ট করছি কারণ ব্লক করা অতীতের একটি বিষয়।

বেশ কিছু লোক অ্যাসিঙ্ক-অপেক্ষার সাথে একটি জম্বি আক্রান্তের তুলনা করছেন এবং আমি এটির চেয়ে যথাযথ বলে মনে করেছি। অ্যাসিঙ্ক কোডটি অন্যান্য এসিঙ্ক কোড পছন্দ করে (একটি অ্যাসিঙ্ক ফাংশনের জন্য অপেক্ষা করার জন্য আপনার একটি অ্যাসিঙ্ক ফাংশন প্রয়োজন)। তাই আরও বেশি বেশি ফাংশন অ্যাসিঙ্ক হয়ে যায় এবং এটি আপনার কোডবেসে বাড়তে থাকে।

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

এবং এখন প্রশ্ন .. যদি আমার সমস্ত কোডটি আস্তে আস্তে অ্যাসিঙ্কটি ঘুরিয়ে নিচ্ছে, তবে কেন এটি ডিফল্টরূপে সমস্ত অ্যাসিনক তৈরি করবেন না?

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

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


8
মানচিত্র চিহ্নিত করার জন্য সি # টিমকে ক্রেডিট দিন। এটি কয়েকশ বছর আগে করা হয়েছিল, "ড্রাগন এখানে শুয়ে আছে"। আপনি একটি জাহাজ সজ্জিত করতে এবং সেখানে যেতে পারে, সম্ভবত আপনি এটির পিছনে সূর্যের জ্বলজ্বল এবং বাতাসের দ্বারা বেঁচে থাকবেন। এবং কখনও কখনও না, তারা কখনও ফিরে আসে না। অনেকটা অ্যাসিঙ্ক / অপেক্ষা করার মতো, এসও ব্যবহারকারীদের প্রশ্নের সাথে ভরে উঠেছে যা তারা মানচিত্র থেকে কীভাবে নামবে বুঝতে পারে নি। যদিও তারা বেশ ভাল সতর্কতা পেয়েছে। এখন এটি তাদের সমস্যা, সি # দলের সমস্যা নয়। তারা ড্রাগনগুলি চিহ্নিত করেছে।
হ্যান্স প্যাস্যান্ট

1
@ যদি আপনি সিঙ্ক এবং অ্যাসিঙ্ক ফাংশনগুলির মধ্যে পার্থক্য অপসারণ করেন, কলিং ফাংশনগুলি যা সিঙ্ক্রোনালি প্রয়োগ করা হয় তা এখনও সমকালীন হবে (আপনার রাইটলাইন উদাহরণের মতো)
টকল

2
"টাস্কের মাধ্যমে রিটার্নের মানটি মোড়ুন <>" আপনার পদ্ধতিটি async(কিছু চুক্তি পূরণের জন্য) না করা না থাকলে এটি সম্ভবত একটি খারাপ ধারণা। আপনি অ্যাসিঙ্কের অসুবিধাগুলি পেয়ে যাচ্ছেন (পদ্ধতি কলগুলির বর্ধিত ব্যয়; awaitকলিং কোডে ব্যবহারের প্রয়োজনীয়তা ), তবে কোনও সুবিধা নেই।
সুইভ

1
এটি একটি সত্যিই আকর্ষণীয় প্রশ্ন তবে এসওয়ের জন্য এটি দুর্দান্ত কোনও ফিট নয়। আমরা এটি প্রোগ্রামারগুলিতে স্থানান্তরিত বিবেচনা করতে পারি।
এরিক লিপার্ট

1
হয়তো আমি কিছু মিস করছি, তবে আমার ঠিক একই প্রশ্ন রয়েছে। যদি অ্যাসিঙ্ক / অপেক্ষারত সর্বদা জোড়ায় আসে এবং কোডটি কার্যকর হওয়ার জন্য অপেক্ষা করতে হয়, তখন কেন কেবল বিদ্যমান .NET ফ্রেমওয়ার্কটি আপডেট করা হয় না এবং অতিরিক্ত কীওয়ার্ড তৈরি না করে ডিফল্টরূপে সেই পদ্ধতিগুলি async - async হওয়া দরকার? কীওয়ার্ড স্প্যাগেটি - ভাষাটি ইতিমধ্যে এটি থেকে পালানোর জন্য ডিজাইন করা হয়েছিল তাতে পরিণত হচ্ছে। আমি মনে করি "ভার" পরামর্শ দেওয়ার পরে তাদের এটি করা বন্ধ করা উচিত ছিল। এখন আমাদের কাছে "গতিশীল", আসিন / অপেক্ষার ... ইত্যাদি ... আপনি কেন কেবল ছেলেরা করবেন না। নেট-ইফাই জাভাস্ক্রিপ্ট? ;))
মনস্তো

উত্তর:


127

প্রথমে, আপনার সদয় কথার জন্য আপনাকে ধন্যবাদ। এটি প্রকৃতপক্ষে একটি দুর্দান্ত বৈশিষ্ট্য এবং এটির একটি ছোট অংশ হতে পেরে আমি আনন্দিত।

যদি আমার সমস্ত কোড আস্তে আস্তে অ্যাসিঙ্কটি ঘুরিয়ে নিচ্ছে, তবে কেন এটি ডিফল্টরূপে সমস্ত এ্যাসিঙ্ক তৈরি করবেন না?

ঠিক আছে, আপনি অত্যুক্তি করছেন; আপনার সমস্ত কোড async পরিণত হয় না। আপনি যখন দুটি "প্লেইন" পূর্ণসংখ্যা একসাথে যোগ করেন, আপনি ফলাফলের অপেক্ষায় থাকবেন না। তৃতীয় ভবিষ্যতের পূর্ণসংখ্যার জন্য আপনি যখন দু'জন ভবিষ্যতের পূর্ণসংখ্যার যোগ একসাথে করেন - কারণ এটি হ'ল এটি একটি পূর্ণসংখ্যা যা আপনি ভবিষ্যতে অ্যাক্সেস পেতে যাচ্ছেন - অবশ্যই আপনি ফলাফলটির জন্য অপেক্ষা করবেন।Task<int>

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

যদি পারফরম্যান্সই একমাত্র সমস্যা হয় তবে অবশ্যই কিছু চতুর অপ্টিমাইজেশন ওভারহেডটি যখন প্রয়োজন হয় না তখন তা স্বয়ংক্রিয়ভাবে সরিয়ে ফেলতে পারে।

তত্ত্বের ক্ষেত্রে তত্ত্ব এবং অনুশীলন একই রকম। অনুশীলনে, তারা কখনও হয় না।

এই ধরণের রূপান্তরটির বিরুদ্ধে আমি আপনাকে তিনটি পয়েন্ট দেব যার পরে একটি অপ্টিমাইজেশন পাস হবে।

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

এর বিপরীতে একটি দ্বিতীয় বিষয় হ'ল সি # এর "রেফারেনশিয়াল স্বচ্ছতা" এর স্তর নেই যা এই ধরণের অপ্টিমাইজেশানকে আরও ট্র্যাকটেবল করে তোলে। "রেফারেন্সিয়াল স্বচ্ছতা" দ্বারা আমি বোঝাচ্ছি যে সম্পত্তিটি যখন মূল্যায়ণ হয় তখন কোনও অভিব্যক্তির মান নির্ভর করে না । মত প্রকাশ 2 + 2মতামত স্বচ্ছ; আপনি চাইলে সংকলন সময়ে মূল্যায়নটি করতে পারেন, বা রানটাইম পর্যন্ত এটি পিছিয়ে রেখে একই উত্তরটি পেতে পারেন। তবে মত x+yপ্রকাশটি সময়ের সাথে সাথে সরানো যায় না কারণ x এবং y সময়ের সাথে সাথে পরিবর্তিত হতে পারে

অ্যাসিঙ্ক কখন পার্শ্ব প্রতিক্রিয়াটি ঘটবে তা নিয়ে যুক্তি দেখানো আরও শক্ত করে তোলে। অ্যাসিঙ্কের আগে, যদি আপনি বলেছিলেন:

M();
N();

এবং M()ছিল void M() { Q(); R(); }, এবং N()ছিল void N() { S(); T(); }, এবং Rএবং Sউত্পাদন পার্শ্ব প্রতিক্রিয়া, তারপর আপনি কি জানেন যে আর এর পার্শ্ব প্রতিক্রিয়া এস এর পার্শ্ব প্রতিক্রিয়া সামনে ঘটবে। তবে যদি আপনার হয়async void M() { await Q(); R(); } হঠাৎ করে উইন্ডোটি চলে যায়। এর R()আগে বা পরে ঘটতে যাচ্ছে কিনা তার আপনার কোনও গ্যারান্টি নেই S()(অবশ্যই M()যদি অপেক্ষা করা না হয়; তবে অবশ্যই এটির Taskপরে অপেক্ষা করা হবে না N()))

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

তৃতীয় বিষয়টির বিপরীতে হ'ল আপনাকে তখন জিজ্ঞাসা করতে হবে "এ্যাসিঙ্ক এত বিশেষ কেন?" আপনি যদি তর্ক করতে চলেছেন যে প্রতিটি ক্রিয়াকলাপ আসলেই একটি হওয়া উচিত Task<T>তখন আপনার প্রশ্নের উত্তর দিতে সক্ষম হওয়া দরকার "কেন নয় Lazy<T>?" বা "কেন নয় Nullable<T>?" বা "কেন নয় IEnumerable<T>?" কারণ আমরা ঠিক সেই কাজটি করতে পারি। কেন এমনটি হওয়া উচিত নয় যে প্রতিটি ক্রিয়াকলাপটি অবনমিত হয় ? অথবা প্রতিটি ক্রিয়াকলাপটি অলসভাবে গণনা করা হয় এবং ফলাফলটি পরবর্তীকালে ক্যাশে করা হয় বা প্রতিটি ক্রিয়াকলাপের ফলাফলটি কেবল একটি একক মানের পরিবর্তে মানগুলির ক্রম হয় । তারপরে আপনাকে সেই পরিস্থিতিগুলি অপ্টিমাইজ করার চেষ্টা করতে হবে যেখানে আপনি জানেন "ওহ, এটি কখনই বাতিল হওয়া উচিত নয়, তাই আমি আরও ভাল কোড তৈরি করতে পারি" ইত্যাদি।

পয়েন্ট হচ্ছে: এটি আমার কাছে পরিষ্কার নয় Task<T> এটি আসলে এত বেশি কাজের পরোয়ানা দেওয়া special

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


অপেক্ষা না করে অ্যাসিঙ্ক ফাংশন ডাকা আমার কাছে বোধগম্য নয় (সাধারণ ক্ষেত্রে)। আমরা যদি এই বৈশিষ্ট্যটি সরিয়ে ফেলি, তবে কোনও ফাংশন অ্যাসিঙ্ক হয় বা না হয় (সংঘটিত এটি কল করে?) সংকলক নিজেই সিদ্ধান্ত নিতে পারত। তারপরে আমরা উভয় ক্ষেত্রেই (অ্যাসিঙ্ক এবং সিঙ্ক) অভিন্ন সিনট্যাক্স পেতে পারি এবং কেবলমাত্র ডিফারেন্টিটার হিসাবে কলগুলিতে অপেক্ষা করতে পারি। বোকচন্দর উপদ্রব সমাধান হয়েছে :)
টকল

আমি আপনার অনুরোধ অনুসারে প্রোগ্রামারগুলিতে আলোচনা
চালিয়েছি

@ এরিকলিপার্ট - বরাবরের মতো খুব সুন্দর উত্তর :) আপনি যদি "উচ্চ বিলম্ব" স্পষ্ট করতে পারতেন তবে আমি আগ্রহী ছিলাম? এখানে কি মিলিসেকেন্ডে একটি সাধারণ পরিসীমা আছে? আমি কেবল অ্যাসিঙ্ক ব্যবহারের জন্য নিম্ন সীমানা রেখাটি কোথায় তা নির্ধারণ করার চেষ্টা করছি কারণ আমি এটির অপব্যবহার করতে চাই না।
ট্র্যাভিস জে

7
@ ট্রাভিজেজে: নির্দেশিকাটি হ'ল 30 এমএসের বেশি ইউআই থ্রেডটি ব্লক করবেন না। এর চেয়ে বেশি এবং আপনি বিরতি দেওয়ার ঝুঁকিটি ব্যবহারকারীর দ্বারা লক্ষ্য করা যায়।
এরিক লিপার্ট

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

23

কেন সমস্ত ফাংশন async করা উচিত নয়?

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

পিছনের দিকের সামঞ্জস্যতা, পাশাপাশি অন্যান্য ভাষার সাথে সামঞ্জস্যতা (ইন্টারপ পরিস্থিতি সহ )ও সমস্যাযুক্ত হয়ে উঠবে।

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

এছাড়াও, অনেকগুলি রুটিন রয়েছে যা তাদের প্রকৃতির দ্বারা, অ্যাসিঙ্ক্রোনাস নয়। যারা সিঙ্ক্রোনাস অপারেশন হিসাবে আরও বোধগম্য। Math.Sqrtহতে বাধ্য Task<double> Math.SqrtAsyncকরা হাস্যকর হবে, উদাহরণস্বরূপ, কারণ এটি অ্যাসিক্রোনাস হওয়ার কোনও কারণ নেই। asyncআপনার অ্যাপ্লিকেশনটি ধাক্কা দেওয়ার পরিবর্তে আপনি সর্বত্রawait প্রচারের কাজ শেষ করবেন ।

এটি বর্তমানের দৃষ্টান্তটিকে পুরোপুরিভাবে ভেঙে দেবে, পাশাপাশি বৈশিষ্ট্যগুলির সাথে সমস্যাগুলি তৈরি করবে (যা কার্যকরভাবে কেবল পদ্ধতির জুড়ি হয় .. তারা কি এ্যাসিঙ্কে যেতে পারে?) এবং কাঠামো এবং ভাষার নকশা জুড়ে অন্যান্য প্রতিক্রিয়া রয়েছে।

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


ঠিক আমি যা লিখতে যাচ্ছিলাম (পারফরম্যান্স), পিছনের সামঞ্জস্যতা অন্য জিনিস হতে পারে, পুরানো ভাষাগুলির সাথে ব্যবহার করা হবে যা
অ্যাসিঙ্ক


@talkol আমি এই চারপাশে ঘুরিয়ে থাকব - কেন উচিত asynchrony জটিলতা প্রতি ফাংশন কল নেবেন?
রিড কোপসি

2
@ ট্যালকোল আমি যুক্তি দিয়েছি যে এটি সত্যই নয় - অ্যাসিক্রোনলি নিজেই এমন বাগগুলি যুক্ত করতে পারে যা ব্লক করার চেয়ে খারাপ ...
রিড কোপসি

1
@ ট্যালকোল এর await FooAsync()চেয়ে সহজ কীভাবে Foo()? এবং কিছু সময় ছোট ডোমিনো এফেক্টের পরিবর্তে আপনি সর্বদা বিশাল ডোমিনো এফেক্ট রাখেন এবং আপনি এটিকে একটি উন্নতি বলেছেন?
সুইভ

4

পারফরম্যান্স একপাশে - async এর উত্পাদনশীলতা ব্যয় হতে পারে। ক্লায়েন্টে (উইনফোর্ডস, ডাব্লুপিএফ, উইন্ডোজ ফোন) এটি উত্পাদনশীলতার জন্য একটি वरदान। তবে সার্ভারে বা অন্যান্য ইউআইআই-এর পরিস্থিতিতে আপনি অর্থ প্রদান করেন উৎপাদনশীলতা। আপনি অবশ্যই সেখানে ডিফল্ট হিসাবে async যেতে চান না। আপনার যখন স্কেলিবিলিটি সুবিধার দরকার হয় তখন এটি ব্যবহার করুন।

মিষ্টি স্থানে থাকলে এটি ব্যবহার করুন। অন্য ক্ষেত্রে, না।


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

2

আমি বিশ্বাস করি যে সমস্ত পদ্ধতির অ্যাসিঙ্ক করার প্রয়োজন নেই - এক্সটেনসিবিলিটি। নির্বাচনী পদ্ধতি তৈরির পদ্ধতিগুলি কেবলমাত্র এ্যাসিঙ্ক কাজ করে যদি আপনার কোডটি কখনই বিকশিত হয় না এবং আপনি জানেন যে পদ্ধতি A () সর্বদা সিপিইউ-আবদ্ধ থাকে (আপনি এটি সিঙ্ক করে রাখেন) এবং পদ্ধতি বি () সর্বদা আই / ও-তে আবদ্ধ থাকে (আপনি এটি অ্যাসিঙ্ক হিসাবে চিহ্নিত করেন)।

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

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


যদিও এটি চূড়ান্ত মন্তব্যের মতো বলে মনে হচ্ছে তবে এর মধ্যে অনেক সত্য রয়েছে। প্রথমত, এই সমস্যার কারণে: "এটি এপিআই এবং সমস্ত কলারকে স্ট্যাক আপ ভেঙে ফেলবে" অ্যাসিঙ্ক / অপেক্ষার ফলে আবেদনকারীকে আরও দৃ tight়তার সাথে যুক্ত করা হয়। উদাহরণস্বরূপ, যদি একটি সাবক্লাস অ্যাসিঙ্ক / অপেক্ষা করতে চায় তবে এটি সহজেই লিস্কভ সাবস্টিটিউশন নীতিটি ভঙ্গ করতে পারে। এছাড়াও, এমন কোনও মাইক্রোসার্ভেসেস আর্কিটেকচারটি কল্পনা করা শক্ত যেখানে বেশিরভাগ পদ্ধতির অ্যাসিঙ্ক / প্রতীক্ষার প্রয়োজন নেই।
ইটসল্যাবাদ জোক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.