उत्पादक होने पर उपभोक्ता को सूचित करने के सुरुचिपूर्ण तरीके?

Question

मैं न्यूनतम कार्यों के साथ एक concurrent_blocking_queue को लागू कर रहा हूँ:

//a thin wrapper over std::queue 
template<typename T> 
class concurrent_blocking_queue 
{ 
    std::queue<T> m_internal_queue; 
    //... 
public: 
    void add(T const & item); 
    T& remove(); 
    bool empty(); 
}; 

मैं producer-consumer problem के लिए इसका उपयोग करना चाहते हैं (मुझे लगता है, यह वह जगह है जहाँ एक का उपयोग करता इस तरह के डेटा संरचनाओं?)। लेकिन मैं एक समस्या पर फंस गया हूं जो है:

उत्पादक होने पर उपभोक्ता को सुंदरता से कैसे सूचित किया जाए? उत्पादक कतार को कब सूचित करेगा जब यह किया जाता है? एक निर्दिष्ट सदस्य फ़ंक्शन को कॉल करके, done() कहें? कतार से अपवाद फेंक रहा है (यानी remove फ़ंक्शन से) एक अच्छा विचार है?

मैं कई उदाहरणों में आया, लेकिन सभी में अनंत लूप है जैसे निर्माता हमेशा के लिए वस्तुओं का उत्पादन करेगा। किसी ने भी रोकथाम की स्थिति के मुद्दे पर चर्चा नहीं की, यहां तक ​​कि wiki article भी नहीं।

Answer 1

मेरे कतार आमतौर पर इस्तेमाल किया है संकेत ( इंटरफ़ेस में एक std::auto_ptr साथ, स्पष्ट रूप से संकेत मिलता है कि इस नहीं रह गया है सूचक का उपयोग कर सकते हैं); अधिकांश भाग के लिए, कतारबद्ध वस्तुएं पॉलिमॉर्फिक थीं, इसलिए गतिशील आवंटन और संदर्भ अर्थशास्त्र की आवश्यकता थी। अन्यथा, “ फ़ाइल ” कतार में ध्वज जोड़ने के लिए बहुत मुश्किल नहीं होना चाहिए। आपको निर्माता पक्ष (close?) पर सेट करने के लिए एक विशेष फ़ंक्शन की आवश्यकता होगी (इसे उसी लॉकिंग प्राइमेटिव्स का उपयोग करके जब आप कतार में लिखते हैं), और फ़ंक्शन को हटाने में लूप को किसी चीज़ के लिए प्रतीक्षा करनी होगी वहां रहें, या कतार बंद हो। बेशक, आपको Fallible मान वापस करने की आवश्यकता होगी, ताकि पाठक यह जान सके कि पढ़ना सफल हुआ या नहीं। साथ ही, मत भूलें कि इस मामले में, आपको यह सुनिश्चित करने के लिए notify_all की आवश्यकता है कि सभी स्थिति पर प्रतीक्षा की जाने वाली प्रक्रियाएं जागृत हों।

बीटीडब्लू: मैं बिल्कुल नहीं देखता कि आपका इंटरफ़ेस कैसे कार्यान्वित किया जा सकता है। T&remove द्वारा लौटाया गया है। असल में, remove कुछ की तरह हो गया है: यहां तक ​​कि myIsDone शर्त के बिना

Fallible<T> 
MessageQueue<T>::receive() 
{ 
    ScopedLock l(myMutex); 
    while (myQueue.empty() && ! myIsDone) 
     myCondition.wait(myMutex); 
    Fallible<T> results; 
    if (!myQueue.empty()) { 
     results.validate(myQueue.top()); 
     myQueue.pop(); 
    } 
    return results; 
} 

, आप कतार से निकालने से पहले एक स्थानीय चर में मूल्य को पढ़ने के लिए है, और आप एक संदर्भ वापस नहीं लौट सकते एक स्थानीय चर के लिए।

बाकी के लिए:

void 
MessageQueue<T>::send(T const& newValue) 
{ 
    ScopedLock l(myMutex); 
    myQueue.push(newValue); 
    myCondition.notify_all(); 
} 

void 
MessageQueue<T>::close() 
{ 
    ScopedLock l(myMutex); 
    myIsDone = true; 
    myCondition.notify_all(); 
} 

Answer 2

मैंने हाल ही में एक डमी "किया" उत्पाद पेश किया है। तो यदि निर्माता "उत्पाद" बना सकता है, तो कहें, ए टाइप करें और टाइप बी, मैंने "पूर्ण" प्रकार का आविष्कार किया है। जब उपभोक्ता "किए गए" प्रकार के उत्पाद से मुकाबला करता है तो यह जानता है कि आगे की प्रक्रिया की आवश्यकता नहीं है।

Answer 3

यह सच है कि एक विशेष "हम कर चुके हैं" संदेश को स्वीकार करना आम है; हालांकि मुझे लगता है कि आउट ऑफ़ बैंड संकेतक के लिए ओपी की मूल इच्छा उचित है। जटिलता को देखो, लोग इन-बैंड समापन संदेश सेट अप करने पर विचार कर रहे हैं! प्रॉक्सी प्रकार, templating; सुखद दुख। मैं कहूंगा कि done() विधि सरल और आसान है, और यह सामान्य मामला बनाता है (हम अभी तक नहीं किए गए हैं) तेज़ और क्लीनर।

मैं बच्चों_फॉक्स से सहमत हूं कि कतारबद्ध होने पर एक try_remove त्रुटि कोड लौटाता है, लेकिन यह स्टाइलिस्ट और वाईएमएमवी है।

संपादित करें: एक कतार है कि कैसे कई निर्माताओं एक बहु-उत्पादकों स्थिति में शेष रहे हैं का ट्रैक रखता है और किया अपवाद iff सभी उत्पादकों तौलिया में फेंक दिया है को जन्म देती है लागू करने के लिए बोनस अंक ;-) नहीं क्या करने जा इन-बैंड संदेशों के साथ !

Answer 4

'रोकना' अक्सर चर्चा नहीं की जाती है क्योंकि यह अक्सर कभी नहीं किया जाता है। उन मामलों में जहां इसकी आवश्यकता होती है, यह अक्सर उच्च स्तर के पी-सी प्रोटोकॉल का उपयोग करके जहर-गोली को जुटाने के लिए जितना आसान और अधिक लचीला होता है क्योंकि यह कतार में अतिरिक्त कार्यक्षमता का निर्माण होता है।

यदि आप वास्तव में ऐसा करना चाहते हैं, तो आप वास्तव में एक ध्वज सेट कर सकते हैं जो प्रत्येक उपभोक्ता को अपवाद उठाने का कारण बनता है, या तो 'तुरंत' या जब भी यह कतार में वापस आता है, लेकिन समस्याएं होती हैं। क्या आपको सिंक्रोनस होने के लिए 'पूर्ण' विधि की आवश्यकता है, यानी। क्या आप चाहते हैं कि सभी उपभोक्ता 'किए गए' रिटर्न, या असीमित, यानी समय से चले गए हों। आखिरी उपभोक्ता धागा एक घटना पैरामीटर कहता है जब अन्य सभी उपभोक्ता चले जाते हैं?

आप उन उपभोक्ताओं के लिए व्यवस्था कैसे कर रहे हैं जो वर्तमान में जागने की प्रतीक्षा कर रहे हैं? कितने इंतजार कर रहे हैं और कितने व्यस्त हैं, लेकिन जब वे अपना काम करते हैं तो कतार में वापस आ जाएंगे? क्या होगा यदि एक या अधिक उपभोक्ता अवरुद्ध कॉल पर फंस गए हों, (शायद उन्हें अनब्लॉक किया जा सकता है, लेकिन इसके लिए किसी अन्य थ्रेड से कॉल की आवश्यकता होती है - आप इसे कैसे करने जा रहे हैं)?

उपभोक्ताओं को यह सूचित करने के लिए कैसे जा रहे हैं कि उन्होंने अपना अपवाद संभाला है और मरने वाले हैं? क्या 'मरने के बारे में' पर्याप्त है, या आपको थ्रेड हैंडल पर इंतजार करने की ज़रूरत है? यदि आपको थ्रेड हैंडल पर इंतजार करना है, तो प्रतीक्षा करने के लिए क्या किया जा रहा है - कतार शटडाउन का अनुरोध करने वाला थ्रेड या अंतिम उपभोक्ता थ्रेड को सूचित करने के लिए?

ओह हाँ - सुरक्षित होने के लिए, आपको निर्माता धागे की व्यवस्था करनी चाहिए जो अपवाद बढ़ाने के लिए 'शट डाउन' स्थिति में कतार में ऑब्जेक्ट्स के साथ बदलना चाहिए।

मैं इन प्रश्नों को उठाता हूं क्योंकि मैंने बहुत समय पहले यह सब किया है। आखिरकार, यह सब काम किया- आईएसएच। जिन वस्तुओं को कतारबद्ध किया गया था, उन्हें 'क्वीडइटम' अपनी विरासत श्रृंखला में डाला गया था, (ताकि नौकरी रद्दीकरण विधि को कतार में उजागर किया जा सके), और कतार को वस्तुओं की थ्रेड-सुरक्षित सूची रखना था धागे द्वारा पॉप-ऑफ बंद लेकिन अभी तक संसाधित नहीं किया गया है।

थोड़ी देर के बाद, मैंने एक विशेष पी-सी कतार के पक्ष में कक्षा का उपयोग बंद कर दिया, जिसमें कोई विशेष शट डाउन तंत्र नहीं था।