স্পিউরিয়াস ওয়েকআপসের ব্যাখ্যাটি এমন বাগের মতো শোনাচ্ছে যা ঠিক করার মতো নয়, এটি কি ঠিক?


30

স্পিউরিয়াস ওয়েকআপস সম্পর্কিত উইকিপিডিয়া নিবন্ধ অনুসারে

"কোনও থ্রেড তার অপেক্ষার অবস্থা থেকে জাগ্রত হতে পারে যদিও কোনও থ্রেড শর্তটি পরিবর্তনশীল হিসাবে চিহ্নিত না করে"।

যদিও আমি এই 'বৈশিষ্ট্য' সম্পর্কে জানতাম কিন্তু আমি কখনই জানতাম না যে আসলে কী কারণে এটি হয়েছিল, একই নিবন্ধে

"উদ্দীপনা জাগানোগুলি অদ্ভুত লাগতে পারে তবে কিছু মাল্টিপ্রসেসর সিস্টেমে শর্ত জাগানো পুরোপুরি অনুমানযোগ্য করে তুলতে পারে সমস্ত শর্তের পরিবর্তনশীল ক্রিয়াকলাপ যথেষ্ট পরিমাণে ধীর হতে পারে" "

বাগের মতো এমন শব্দ যা ঠিক করা ঠিক নয়, তা কি ঠিক?


1
সম্পর্কিত: "কেন pthread_cond_wait কৃত্রিম wakeups আছে?", stackoverflow.com/questions/8594591/...
ফ্লোরিয়ান Castellane

উত্তর:


39

তাত্পর্যপূর্ণ জাগানোগুলির টিএল; ডিআর অ্যাস্পশন ("চুক্তি") হ'ল থ্রেড শ্যাডুলারের বাস্তবিকভাবে দৃ rob় বাস্তবায়নের অনুমতি দেওয়ার জন্য করা একটি বুদ্ধিমান স্থিতিশীল সিদ্ধান্ত।

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

উত্সাহী জাগ্রতগুলির ধারণা প্রবর্তনের আরও অনেক জোরালো কারণ এই উত্তরে এসও- তে এই উত্তরটিতে সরবরাহ করা হয়েছে যা সেই নিবন্ধের একটি (পুরানো সংস্করণ) সরবরাহিত অতিরিক্ত বিবরণের উপর ভিত্তি করে:

উত্সাহী জাগরণের বিষয়ে উইকিপিডিয়া নিবন্ধটিতে এই বিবরণটি রয়েছে:

pthread_cond_wait()Linux এ ফাংশন ব্যবহার করে বাস্তবায়িত হয় futexসিস্টেম কল। EINTRপ্রক্রিয়াটি সংকেত পেলে লিনাক্সের প্রতিটি ব্লকিং সিস্টেম কল হঠাৎ করে ফিরে আসে । ... pthread_cond_wait()অপেক্ষার পুনরায় আরম্ভ করতে পারবেন না কারণ এটি futexসিস্টেম কলের বাইরে খুব অল্প সময়েই সত্যিকারের জাগানো অনুভব করতে পারে ...

কেবল এটিকে ভাবুন ... যে কোনও কোডের মতো, থ্রেড শিডিয়ুলার অন্তর্নিহিত হার্ডওয়্যার / সফ্টওয়্যারটিতে অস্বাভাবিক কিছু ঘটার কারণে অস্থায়ী ব্ল্যাকআউট অনুভব করতে পারে। অবশ্যই এটি যথাসম্ভব বিরল হওয়ার জন্য যত্ন নেওয়া উচিত, তবে যেহেতু 100% মজবুত সফ্টওয়্যার বলে কিছু নেই তাই এটি ঘটতে পারে বলে ধরে নেওয়া যুক্তিসঙ্গত এবং যদি শিডিয়ুলার এটি সনাক্ত করে তবে ক্ষেত্রে সুদৃ recovery় পুনরুদ্ধারের যত্ন নেওয়া উচিত eg অনুপস্থিত হার্টবিট পর্যবেক্ষণ করে )।

এখন, শিডিউলার কীভাবে পুনরুদ্ধার করতে পারে তা বিবেচনায় নিয়ে যে ব্ল্যাকআউট চলাকালীন এটি অপেক্ষা থ্রেডগুলি অবহিত করার উদ্দেশ্যে কিছু সংকেত মিস করতে পারে? শিডিউলার যদি কিছু না করে তবে উল্লিখিত "দুর্ভাগ্য" থ্রেডগুলি কেবল স্থায়ী হয়ে থাকবে, চিরকাল অপেক্ষা করা হবে - এড়াতে, শিডিয়ুলার কেবলমাত্র সমস্ত অপেক্ষার থ্রেডে একটি সংকেত পাঠাত send

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


থ্রেড দৃষ্টিকোণ থেকে, এটি কিছুটা পোস্টেলের আইনের সাথে সাদৃশ্যপূর্ণ (ওরফে দৃ rob ়তা নীতি ),

আপনি যা করেন তাতে রক্ষণশীল হন, আপনি অন্যের কাছ থেকে যা গ্রহণ করেন তাতে উদার হন

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


10
উঘ ... পোষ্টেলের আইন ... এইচটিএমএল এবং সমস্ত ধরণের ওয়েব প্রযুক্তির মধ্যে এত ক্রেপ ফেলে দেওয়ার কারণ (উদাহরণস্বরূপ, খারাপ ট্যাগ নেস্টিংয়ের এইচটিএমএল স্বীকৃতি)। একপাশে, ভাল উত্তর।
টমাস এডিং

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

2
@ পেসারিয়র: একটি ভুল আউটপুট ফিরিয়ে ফাংশনটি পোস্টেলের আইন (রক্ষণশীল অংশ) অনুসরণ করে না।
YvesgereY

@ পেসার: ওটিওএইচ, অন্যান্য উপাদানগুলিকে কঠোর করার দাবি জানিয়ে যাতে বাগগুলি আগে ধরা যায় তবে একটি আকর্ষণীয় অবস্থান, এটি 'ফেল ফাস্ট' নীতি এবং 'চুক্তি ভিত্তিক' নকশার দিক থেকে ভুল হয়েছে।
YvesgereY

1

রেস শর্তটি মোকাবেলা করার জন্য কলার কোডের যেভাবেই একই চিকিত্সা (শর্ত পরীক্ষা করা) ব্যবহার করা উচিত, এটি ঠিক করার মতো নয়।

দুটি সমস্যার জন্য একটি চিকিত্সা, যা আমি নিম্নলিখিত দ্বারা সংক্ষেপে বলছি:

উদ্দীপনা জাগানো: শর্তটি প্রতিষ্ঠিত হওয়ার আগে ওয়েটিং থ্রেড নির্ধারিত scheduled
জোর করে ওভারস্লিপ: শর্তটি আবার মিথ্যা বলার পরে অপেক্ষার থ্রেড নির্ধারিত হয়েছে।

যেহেতু পরবর্তী ঘটনাটি ঘটতে পারে, তাই কেউ কেউ চুক্তিতে উত্সাহী জাগরণ প্রবর্তন করে চলেছে:

  • প্রাকটিক লুপগুলির প্রয়োজনের দ্বারা ভাল অনুশীলনগুলি প্রয়োগ করতে।
  • শিডিউল বাস্তবায়নের জন্য কিছু স্বাধীনতা দেওয়ার জন্য (জরুরী পুনরুদ্ধারের বিকল্প সহ, @ জাগান্ট দ্বারা নির্দেশিত)।

এসও রেফারেন্স


আমি এটি +1 করতে চাই, তবে এই ধারণাটির জন্য যে কেউ জোর করে ঘুমের সমাধানের জন্য কলকারীদেরকে প্রাকটিক লুপগুলি যুক্ত করতে ইচ্ছাকৃতভাবে উত্সাহী জাগরণগুলি প্রবর্তন করেছিলেন। আমি যে অকল্পনীয়।
রূখ

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