কেন pthread_cond_wait উত্সাহী জাগ্রত আছে?

Question

ম্যান পৃষ্ঠাটি উদ্ধৃত করতে:

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

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

কেনpthread_cond_wait তীব্রভাবে ফিরে আসে ? কেন এটি গ্যারান্টি দিতে পারে না যে এটি কেবলমাত্র যখন সঠিকভাবে সংকেত দেওয়া হয়েছে তখনই তারা জেগে উঠবে? এর উত্সাহী আচরণের কারণ কি কেউ ব্যাখ্যা করতে পারেন?

Comments

আমি কল্পনা করব যখনই প্রক্রিয়াটি কোনও সংকেত ধরবে তখন ফিরে আসার সাথে এর কিছু করার আছে। একটি সংকেত বাধাগ্রস্ত হওয়ার পরে বেশিরভাগ * নিক্স ব্লকিং কল পুনরায় আরম্ভ করে না; তারা কেবল একটি ত্রুটি কোড সেট / ফিরিয়ে দিয়েছে যা বলে যে একটি সংকেত ঘটেছে।

— সিএওও

@ সিএইচও: যদিও নোট করুন যেহেতু শর্ত ভেরিয়েবলগুলি যেভাবেই উত্সাহী জাগরণের জন্য অন্যান্য কারণ রয়েছে, একটি সংকেত পরিচালনা করা এর জন্য ত্রুটি নয় pthread_cond_(timed)wait: "যদি একটি সংকেত সরবরাহ করা হয় ... তবে থ্রেডটি শর্ত পরিবর্তনের অপেক্ষায় পুনরায় শুরু হয় যেন এটি ছিল বাধা দেওয়া হয়নি, বা উদ্দীপনা জাগানোর কারণে এটি শূন্য ফিরে আসবে "। অন্যান্য অবরুদ্ধ ফাংশনগুলি EINTRযখন সিগন্যাল দ্বারা বাধাগ্রস্থ হয় (উদাহরণস্বরূপ read), বা পুনরায় শুরু করার প্রয়োজন হয় (যেমন pthread_mutex_lock)। সুতরাং যদি উত্সাহী জাগরণের জন্য অন্য কোনও কারণ না থাকে তবে সেগুলির মধ্যে দুটির pthread_cond_waitমতোই সংজ্ঞা দেওয়া যেতে পারে।

— স্টিভ জেসোপ

উইকিপিডিয়া সম্পর্কিত সম্পর্কিত নিবন্ধ: উদ্দীপনা জাগানো

— প্লেকে

দরকারী ভ্লাদিমির প্রস: স্পিউরিয়াস ওয়েকআপস ।

— iammilind

অনেক ফাংশন সম্পূর্ণরূপে তাদের কাজ পুরোপুরি করতে পারে না (বাধা দেওয়া I / O) এবং পর্যবেক্ষণ ফাংশনগুলি কোনও ডিরেক্টরিতে পরিবর্তন পরিবর্তিত বা ফিরে ফিরে ফিরে আসার মতো অ ইভেন্ট ইভেন্ট গ্রহণ করতে পারে। সমস্যা কি?

— কৌতূহলী

Answer 1

নিম্নলিখিত ব্যাখ্যাটি ডেভিড আর বুটেনহফ "প্রোগ্রামিং উইথ পসিক্স থ্রেডস" (পৃষ্ঠা 80) এ দিয়েছেন:

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

নিম্নলিখিত comp.programming.threads আলোচনা তিনি নকশার পিছনে চিন্তাভাবনা প্রসারিত করেছেন:

প্যাট্রিক ডয়েল লিখেছেন: 
> নিবন্ধে টম পেইন লিখেছেন: 
>> কাজ কিলহেকু লিখেছেন: 
>>: এটি তাই কারণ বাস্তবায়ন কখনও কখনও সন্নিবেশ এড়াতে পারে না 
>>: এই উদ্দীপনা জাগ্রত; এগুলি রোধ করা ব্যয়বহুল হতে পারে।

>> তবে কেন? কেন এই এত কঠিন? উদাহরণস্বরূপ, আমরা কি কথা বলছি
>> এমন পরিস্থিতিতে যেখানে একটি সংকেত আসার সাথে সাথে অপেক্ষা করার সময় শেষ হয়? 

> আপনি জানেন, আমি অবাক হয়েছি যে পাইথ্রেডগুলির ডিজাইনাররা এভাবে যুক্তি ব্যবহার করেছিলেন: 
> শর্ত ভেরিয়েবলের ব্যবহারকারীদের যেভাবেই প্রস্থান করার সময় শর্তটি পরীক্ষা করতে হবে, 
> সুতরাং আমরা অনুমতি দিলে আমরা তাদের উপর কোনও অতিরিক্ত বোঝা চাপব না 
> উদ্দীপনা জাগানো; এবং যেহেতু এটি অনুমেয় যে মজাদারদের অনুমতি দেয়
> জাগ্রতগুলি দ্রুত বাস্তবায়ন করতে পারে, এটি কেবল তখনই সহায়তা করতে পারে 
> তাদের অনুমতি দিন। 

> তাদের মনে কোনও বিশেষ বাস্তবায়ন নাও থাকতে পারে। 

আপনি আসলে একেবারেই দূরে নন, আপনি এটিকে যথেষ্ট পরিমাণে ধাক্কা না দিলে। 

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

আমরা সেই উদ্দেশ্যটি বিভিন্ন স্তরের ন্যায়সঙ্গততার সাথে অনুসরণ করেছি। প্রথমটি ছিল
"ধর্মীয়ভাবে" একটি লুপ ব্যবহার করে অ্যাপ্লিকেশনটিকে তার নিজস্ব অসম্পূর্ণতা থেকে রক্ষা করে 
কোডিং অনুশীলন। দ্বিতীয়টি হ'ল বিমূর্তভাবে কল্পনা করা কঠিন ছিল না
মেশিন এবং বাস্তবায়ন কোড যা উন্নতি করতে এই প্রয়োজনীয়তাটি কাজে লাগাতে পারে 
অপ্টিমাইজেশনের মাধ্যমে গড় শর্ত অপেক্ষার ক্রিয়াকলাপ 
সিঙ্ক্রোনাইজেশন প্রক্রিয়া। 
/ ------------------ [ডেভিড.বুটেন ... @ কম্পেক.কম] ------------------ \ 
| কমপ্যাক কম্পিউটার কর্পোরেশন পসিক্স থ্রেড আর্কিটেক্ট |
| আমার বই: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

Comments

মূলত এটি কিছুই বলে না। "এটি জিনিসগুলিকে দ্রুততর করে তুলতে পারে" প্রাথমিক চিন্তা ছাড়া এখানে কোনও ব্যাখ্যা দেওয়া হয়নি তবে কীভাবে বা এটি আদৌ কী করে তা কেউ জানে না।

— বোগদান আয়নিটজা

Answer 2

কমপক্ষে দুটি জিনিস রয়েছে 'স্পিউরিয়াস ওয়েকআপ' ​​এর অর্থ হতে পারে:

• শর্তটিতে pthread_cond_waitকোনও কল pthread_call_signalবা সমস্যা না থাকলেও একটি থ্রেড ব্লক করা কল থেকে ফিরে আসতে পারে pthread_cond_broadcast।
• কোনও থ্রেড pthread_cond_waitকল করার কারণে pthread_cond_signalবা তার পরিবর্তে রিটার্নগুলিতে অবরুদ্ধ হয়েছে pthread_cond_broadcast, তবে মিউটেক্সকে পুনরায় জিজ্ঞাসা করার পরে অন্তর্নিহিত ভবিষ্যদ্বাণীটি আর সত্য হয় না।

তবে পরবর্তী অবস্থাটি শর্ত পরিবর্তনশীল প্রয়োগটি পূর্বের ক্ষেত্রে অনুমতি না দেয় এমনকি যদি ঘটতে পারে। একজন প্রযোজক ভোক্তা সারি এবং তিনটি থ্রেড বিবেচনা করুন।

• থ্রেড 1 সবেমাত্র একটি উপাদান সন্ধান করেছে এবং মিটেক্সকে মুক্তি দিয়েছে এবং সারিটি এখন খালি is থ্রেডটি কিছু সিপিইউতে অর্জন করা উপাদানটির সাথে যা কিছু করছে তা করছে।
• থ্রেড 2 একটি উপাদান শনাক্ত করার চেষ্টা করে, তবে pthread_cond_waitসংকেত / সম্প্রচারের অপেক্ষায় থাকা কলটিতে নীরবতা, কলগুলি এবং ব্লকগুলির নীচে চেক করা অবস্থায় সারিটি ফাঁকা থাকার সন্ধান করে ।
• থ্রেড 3 মিউটেক্সটি গ্রহণ করে, একটি নতুন উপাদান সারিটিতে সন্নিবেশ করায়, শর্ত পরিবর্তনশীলকে জানিয়ে দেয় এবং লকটি প্রকাশ করে।
• থ্রেড 3 থেকে বিজ্ঞপ্তির প্রতিক্রিয়া হিসাবে শর্তের অপেক্ষায় থাকা থ্রেড 2 চালানোর সময় নির্ধারিত হয়েছে।
• তবে থ্রেড 2 সিপিইউতে উঠতে এবং কাতার লকটি ধরতে পরিচালিত হওয়ার আগে, থ্রেড 1 তার বর্তমান কাজটি সম্পূর্ণ করে এবং আরও কাজের জন্য কাতারে ফিরে আসে। এটি সারি লকটি অর্জন করে, প্রিডিকেটটি পরীক্ষা করে এবং দেখায় যে কাতারে কাজ রয়েছে। এটি থ্রেড 3 sertedোকানো, লকটি প্রকাশ করে এবং থ্রেড 3 থ্রেড করা আইটেমটির সাথে যা কিছু করে তা আবিষ্কার করে।
• থ্রেড 2 এখন একটি সিপিইউতে পৌঁছে লকটি পেয়েছে, কিন্তু যখন এটি প্রিকিকেটটি পরীক্ষা করে তখন এটি দেখতে পায় যে সারিটি খালি রয়েছে। আইটেম 1 'চুরি' থ্রেড, তাই জাগানো উত্সাহজনক বলে মনে হচ্ছে। থ্রেড 2 এর জন্য আবার শর্তটি অপেক্ষা করা দরকার।

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

Comments

হ্যাঁ. প্রয়োজনীয়, একটি ঘটনাকে একটি গণনার সাথে একটি সিঙ্ক্রোনাইজেশন ব্যবস্থার পরিবর্তে ব্যবহার করা হয়। দুঃখজনকভাবে, এটি উপস্থিত হয় যে পসিক্স সেম্যাফোরগুলি (যাইহোক লিনাক্সে) স্পিরিয়াস ওয়েকআপগুলিরও সাপেক্ষে। আমি এটিকে কিছুটা আশ্চর্যজনক বলে মনে করি যে সিঙ্ক্রোনাইজেশন আদিমদের একটি মৌলিক কার্যকারিতা ব্যর্থতা কেবল 'সাধারণ' হিসাবে স্বীকৃত এবং ব্যবহারকারীর পর্যায়ে কাজ করা উচিত :( সম্ভবতঃ কোনও সিস্টেম কল নথিভুক্ত হলে বিকাশকারীরা সামনের দিকে থাকবে একটি 'স্পিউরিয়াস সেগফল্ট' বিভাগ বা সম্ভবত 'ভুল URL- এর সাথে স্পিউরিয়াস সংযোগ স্থাপন' বা 'ভুল ফাইলটির উদ্বোধন খোলার' সাথে

— মার্টিন জেমস

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

— কিউবিকসফট

@ মার্টিনজেমস - ক্লাসিক "উত্সাহী" ইআইএনটিআর সম্পর্কে কীভাবে? আমি সম্মত হব যে EINTR এর জন্য একটি লুপে ক্রমাগত পরীক্ষা করা খুব বিরক্তিকর এবং কোডটি বরং কুরুচিপূর্ণ করে তোলে তবে বিকাশকারীরা এলোমেলোভাবে বিরতি এড়াতে যাইহোক এটি করেন।

— কিউবিকসফট

@ ইওলা না এটি পারবেন না, কারণ আপনার চারপাশে একটি মিউটেক্স লক করার কথা pthread_cond_signal/broadcastএবং আপনি এটি করতে সক্ষম হবেন না, যতক্ষণ না ফোনটি মুটেক্সকে আনলক করা হয় pthread_cond_wait।

— a3f

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

— কুইকসপ্লসোন

Answer 3

Pthread_cond_signal এর "কন্ডিশন সিগন্যাল দ্বারা একাধিক জাগরণ" বিভাগে pthread_cond_wait এবং pthread_cond_signal এর উদাহরণ বাস্তবায়ন রয়েছে যা উত্সাহী জাগরণ জড়িত।

Comments

আমি মনে করি এই উত্তরটি যতদূর যায় ভুল। এই পৃষ্ঠায় নমুনা প্রয়োগের "নোটিফাইড উইন্ডো" এর প্রয়োগ রয়েছে যা "সকলকে অবহিত করুন" এর সমতুল্য; কিন্তু এটি আসলে উৎপন্ন বলে মনে হচ্ছে না কৃত্রিম wakeups। কোনও থ্রেড জেগে ওঠার একমাত্র উপায় হ'ল কিছু সূত্রে "সকলকে বিজ্ঞাপিত করুন" বা অন্য কোনও থ্রেড দ্বারা "জিনিসটি অবহিত করুন" - যা সত্যই- "সকলকে অবহিত করুন" thing

— কুক্সপ্লসোন

Answer 4

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

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

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