एक सेमफोर के एक कंडीशन/म्यूटेक्स कार्यान्वयन के लिए "प्रतीक्षा()" फ़ंक्शन में "जबकि" लूप की आवश्यकता क्यों होती है?

Question

मैं ध्यान से निम्नलिखित तो सवाल करने के लिए स्वीकार किए जाते हैं जवाब का अध्ययन किया गया है:

void wait() 
{ 
    boost::mutex::scoped_lock lock(mutex_); 
    while(!count_) 
     condition_.wait(lock); 
    --count_; 
} 

मैं समझने की कोशिश कर रहा हूँ: C++0x has no semaphores? How to synchronize threads?

कि जवाब में सेमाफोर कार्यान्वयन में, यहाँ wait() समारोह के कार्यान्वयन है while(!count_) स्थिति का उद्देश्य।

एक और तो सवाल (How does this implementation of semaphore work?) का जवाब इंगित करता है कि notify_one() हालत चर पर कहा जाता है जब यह है कि यह संभव है कि से अधिक एक धागा कि हालत चर पर इंतज़ार कर उठ जाएगा - इसलिए के लिए की जरूरत while पाश। मैं यह पुष्टि करना चाहता हूं - क्या यह पूर्ण और/या सही उत्तर है, या अन्य कारण हैं कि while पाश आवश्यक क्यों है?

यदि एक से अधिक धागे जागते हैं, तो कौन सा थ्रेड म्यूटेक्स का मालिक है? जितना अधिक मैं इसके बारे में सोचता हूं, उतना ही बीमार परिभाषित ऐसा लगता है कि notify_one() पर एक कॉल के कारण एक से अधिक धागे जाग सकते हैं। count_ मान 0 से अधिक मानने के लिए दोनों woken-up धागे के लिए संभव नहीं होगा, और count_ दोनों की कमी के लिए आगे बढ़ें, जिसके परिणामस्वरूप count_ 0 से कम मान, और सेमफोर के उद्देश्य (और शुद्धता) को हराया जाए?

Answer 1

spurious wakeups हो सकता है, या notify_one कार्यान्वयन विवरण के कारण एक से अधिक धागे जाग सकता है, जैसा कि आपने पहले ही उल्लेख किया है।

एकाधिक धागे को जागने का मतलब यह नहीं है कि उनमें से सभी एक ही समय में संरक्षित अनुभाग में प्रवेश कर सकते हैं, इसका मतलब यह है कि जब थ्रेडए लॉक जारी करता है, थ्रेडबी (जो पिछले उदाहरण में थ्रेडए के साथ जाग गया था) भी संरक्षित खंड में प्रवेश करने के लिए मिलता है। इस समय तक थ्रेडए ने अपना काम पहले ही कर लिया है, इसलिए थ्रेडब को उसी स्थिति में count वैरिएबल नहीं दिखाई देगा क्योंकि थ्रेडए ने इसे पाया था।