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

तथ्य यह है कि यह ढांचा पहले से ही काफी पुराना है, यह कई बार नाटकीय रूप से बदल गया है। यहां तक ​​कि उनके वर्तमान अवतार, एसओबीजेलाइज़र -5 में कई बदलाव हुए हैं, दोनों गंभीर और ऐसा नहीं है। इसके अलावा, हम संगतता के प्रति संवेदनशील नहीं हैं, और परिवर्तन करना जो संगतता को तोड़ते हैं, हमारे लिए सिर्फ इस पर निर्णय लेने के लिए बहुत गंभीर है।

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

और अब, फ्रेमवर्क के डेवलपर्स के रूप में, हमें एक या दूसरे समाधान के पक्ष में चुनाव करना होगा। या किसी को यह स्वीकार करना चाहिए कि उनमें से कोई भी संतोषजनक नहीं है और इसलिए, कुछ और का आविष्कार किया जाना चाहिए। SObjectizer के इतिहास के दौरान इस तरह के निर्णय एक से अधिक बार किए जाने थे। यदि कोई ऐसे ढांचे के डेवलपर के जूते में महसूस करने में रुचि रखता है, तो आपको बिल्ली का स्वागत है।

मूल समस्या

तो, संक्षेप में मूल समस्या का सार है। अपने अस्तित्व की शुरुआत से ही, SObjectizer में निम्नलिखित विशेषता थी: एक टाइमर संदेश रद्द करना इतना आसान नहीं है। टाइमर के तहत समझा जाएगा, सबसे पहले, एक विलंबित संदेश। यानी एक संदेश जिसे प्राप्तकर्ता को तुरंत नहीं भेजा जाना चाहिए, लेकिन कुछ समय बाद। उदाहरण के लिए, हम send_delayed को 1s के ठहराव के साथ करते हैं। इसका मतलब यह है कि वास्तव में संदेश send_delayed कॉल के बाद टाइमर 1s द्वारा भेजा जाएगा।

एक लंबित संदेश, सिद्धांत रूप में, रद्द किया जा सकता है। यदि संदेश अभी भी टाइमर के कब्जे में है, तो रद्द होने के बाद संदेश कहीं भी नहीं जाएगा। इसे टाइमर द्वारा और इसे फेंक दिया जाएगा। लेकिन अगर टाइमर ने पहले ही एक संदेश भेज दिया है और यह अब प्राप्त एजेंट के लिए अनुरोध कतार में है, तो टाइमर को रद्द करने से काम नहीं चलेगा। एप्लिकेशन कतार से संदेश हटाने के लिए SObjectizer में कोई तंत्र नहीं है।

समस्या को कम से कम दो कारकों द्वारा संयोजित किया जाता है।

सबसे पहले, SObjectizer 1: N मोड में डिलीवरी का समर्थन करता है, अर्थात। यदि संदेश बहु-उपभोक्ता mbox को भेजा गया था, तो संदेश एक कतार में नहीं होगा, बल्कि एक बार में N प्राप्तकर्ताओं के लिए कई कतारों में होगा।

दूसरे, SObjectizer में डिस्पैचर तंत्र का उपयोग किया जाता है और डिस्पैचर बहुत अलग हो सकते हैं, जिसमें उपयोगकर्ता द्वारा उनकी विशिष्ट आवश्यकताओं के लिए लिखा गया है। अनुरोध कतार प्रेषणकर्ताओं द्वारा प्रबंधित की जाती हैं। और डिस्पैचर के इंटरफेस में एक आवेदन वापस लेने के लिए कोई कार्यक्षमता नहीं है जो पहले ही डिस्पैचर में स्थानांतरित हो चुकी है। लेकिन भले ही इंटरफ़ेस में ऐसी कार्यक्षमता अंतर्निहित थी, यह इस तथ्य से बहुत दूर है कि इसे सभी मामलों में प्रभावी ढंग से लागू किया जा सकता है। इस तथ्य का उल्लेख नहीं करने के लिए कि इस तरह की कार्यक्षमता नए प्रेषणकर्ताओं को विकसित करने की जटिलता को बढ़ाएगी।

सामान्य तौर पर, उद्देश्यपूर्ण रूप से, यदि टाइमर ने पहले से ही प्राप्तकर्ता को लंबित संदेश भेजा है, तो SObjectizer को संदेश के इस उदाहरण को वितरित करने के लिए मजबूर नहीं करना वर्तमान में असंभव है।

वास्तव में, यह समस्या आवधिक संदेशों के लिए भी प्रासंगिक है (यानी संदेश कि टाइमर को समय-समय पर पूर्वनिर्धारित समय अंतराल पर भेजना चाहिए)। लेकिन व्यवहार में, लंबित संदेश को रद्द करने की तुलना में आवधिक संदेशों को रद्द करना बहुत कम आवश्यक है। कम से कम हमारे व्यवहार में तो ऐसा है।

अभी क्या किया जा सकता है?

तो, यह समस्या कोई नई बात नहीं है और लंबे समय तक इससे निपटने के बारे में सिफारिशें हैं।

लंबित संदेश के अंदर अद्वितीय आईडी

सबसे आसान तरीका एक काउंटर रखना है। एजेंट के पास एक काउंटर है; एक लंबित संदेश भेजते समय, संदेश में वर्तमान काउंटर मूल्य भेजा जाता है। जब कोई संदेश रद्द किया जाता है, तो एजेंट का काउंटर बढ़ जाता है। संदेश प्राप्त होने पर, संदेश से मूल्य के साथ एजेंट में वर्तमान काउंटर मूल्य की तुलना की जाती है। यदि मान मेल नहीं खाते, तो संदेश अस्वीकार कर दिया जाता है:

class demo_agent : public so_5::agent_t { struct delayed_msg final { int id_; ... }; int expected_msg_id_{}; so_5::timer_id_t timer_; void on_some_event() { //   . //   send_periodic, ..    //  timer_id   . timer_ = so_5::send_periodic<delayed_msg>(*this, 25s, //     . 0s, //    . //      delayed_msg, //      id   . ++expected_msg_id_, ... //  . ); ... } void on_cancel_event() { //   ,        //   .   : timer_.reset(); //     . ++expected_msg_id_; //   id-. ... } void on_delayed_msg(mhood_t<delayed_msg> cmd) { //     id    //  . if(expected_msg_id_ == cmd->id_) { ... //  . } } }; 

इस पद्धति के साथ समस्या यह है कि एजेंट डेवलपर को इन काउंटरों को बनाए रखने से हैरान होना चाहिए। और यदि विलंबित संदेश के रूप में हमें किसी और के संदेश को भेजने की आवश्यकता है जो किसी और ने किया है, और जिसमें कोई id_ फ़ील्ड नहीं है, तो हम खुद को एक कठिन स्थिति में पाते हैं।

हालांकि, दूसरी ओर, यह वर्तमान में मौजूद सबसे प्रभावी तरीका है।

विलम्बित संदेश के लिए अद्वितीय mbox का उपयोग करें

एक और तरीका जो अच्छी तरह से काम करता है वह है देरी संदेश के लिए एक अद्वितीय मेलबॉक्स (एमबॉक्स) का उपयोग करना। इस स्थिति में, हम प्रत्येक लंबित संदेश के लिए एक नया mbox बनाते हैं, इसकी सदस्यता लेते हैं और इस संदेश को लंबित संदेश भेजते हैं। जब किसी संदेश को रद्द करने की आवश्यकता होती है, तो हम केवल mbox सदस्यता हटाते हैं।

 class demo_agent : public so_5::agent_t { struct delayed_msg final { ... //   id_   . }; so_5::mbox_t timer_mbox_; //   . so_5::timer_id_t timer_; void on_some_event() { //        mbox //     . timer_mbox_ = so_environment().create_mbox(); some_state.event(time_mbox_, ...); another_state.event(time_mbox_, ...); ... //    . timer_ = so_5::send_delayed<delayed_msg>( so_environment(), timer_mbox_, //     . 25s, 0s, ... //    delayed_msg. ); } void on_cancel_event() { //        mbox. timer_.reset(); so_drop_subscription_for_all_states(timer_mbox_); } void on_delayed_msg(mhood_t<delayed_msg> cmd) { //     ,   //    . ... } }; 

यह विधि पहले से ही अन्य लोगों के संदेशों के साथ काम कर सकती है, जिसके अंदर कोई विशिष्ट पहचानकर्ता नहीं है। लेकिन इसके लिए डेवलपर से श्रम और ध्यान भी आवश्यक है।

उदाहरण के लिए, उपरोक्त अवतार में, इस तथ्य से कोई सुरक्षा नहीं है कि एक लंबित संदेश पहले ही भेजा जा चुका है। एक अच्छे तरीके से, एक नया लंबित संदेश भेजने से पहले, आपको हमेशा on_cancel_event () से कार्रवाई करनी चाहिए, अन्यथा एजेंट के पास इसके लिए अनावश्यक सदस्यताएँ होंगी।

इस समस्या का समाधान पहले क्यों नहीं किया गया?

यहां सब कुछ काफी सरल है: वास्तव में, यह इतनी गंभीर समस्या नहीं है जितनी यह लग सकती है। वास्तविक जीवन में कम से कम आपको अक्सर इससे जूझना नहीं पड़ता है। आमतौर पर लंबित और आवधिक संदेश बिल्कुल रद्द नहीं किए जाते हैं (यही वजह है कि, send_delayed फ़ंक्शन टाइमर_आईडी वापस नहीं करता है)। और जब रद्दीकरण की आवश्यकता उत्पन्न होती है, तो आप ऊपर वर्णित तरीकों में से एक का उपयोग कर सकते हैं। या यहां तक ​​कि कुछ अन्य का उपयोग करें। उदाहरण के लिए, अलग-अलग एजेंट बनाएं जो लंबित संदेश को संसाधित करेगा। जब कोई लंबित संदेश रद्द करने की आवश्यकता हो, तो ये एजेंट deregistered हो सकते हैं।

इसलिए, अन्य कार्यों की पृष्ठभूमि के खिलाफ, जिन्होंने हमें सामना किया, एक लंबित संदेश की गारंटीकृत रद्दीकरण को सरल बनाना इतनी प्राथमिकता नहीं थी क्योंकि इस समस्या को हल करने के लिए हमारे संसाधनों को खर्च करना था।

अब समस्या प्रासंगिक क्यों है?

यहाँ सब कुछ उतना ही सरल है। एक ओर, हाथ आखिरकार पहुंच गए।

दूसरी ओर, जब नए लोगों को जिनके पास काम करने का अनुभव नहीं था, वे SObjectizer का उपयोग करना शुरू करते हैं, तो टाइमर के रद्द होने के साथ यह सुविधा उन्हें बहुत आश्चर्यचकित करती है। सुखद आश्चर्य की बात नहीं है। और यदि ऐसा है, तो मैं हमारे टूल को जानने के नकारात्मक इंप्रेशन को कम करना चाहूंगा।

इसके अलावा, हमारे अपने कार्य थे, हमें लंबित संदेशों को लगातार रद्द करने की आवश्यकता नहीं थी। और नए उपयोगकर्ताओं के अपने कार्य हैं, शायद सब कुछ चारों ओर का रास्ता है।

समस्या का नया बयान

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

समय-समय पर यह अवसर मांग में है। उदाहरण के लिए, कल्पना करें कि हमारे पास दो प्रकार के कई इंटरेस्टिंग एजेंट हैं: entry_point (क्लाइंट से अनुरोध स्वीकार करता है), और प्रोसेसर (प्रक्रिया अनुरोध):



Entry_point एजेंट प्रोसेसर एजेंट को अनुरोध भेजते हैं, जो उन्हें यथासंभव संसाधित करता है और entry_point एजेंटों को जवाब देता है। लेकिन कई बार, entry_point को लग सकता है कि पहले भेजे गए अनुरोध को संसाधित करने की अब आवश्यकता नहीं है। उदाहरण के लिए, क्लाइंट ने एक रद्द आदेश भेजा है या क्लाइंट "गिर गया" और अब आपको इसके अनुरोधों को संसाधित करने की आवश्यकता नहीं है। अब, यदि अनुरोध संदेश प्रोसेसर एजेंट द्वारा कतारबद्ध हैं, तो आप उन्हें वापस नहीं ले सकते। और यह उपयोगी होगा।

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

"रिकॉल संदेशों" के कार्यान्वयन के साथ आने का प्रयास

तो, आपको "रिकॉल संदेश" की अवधारणा को पेश करने और SObjectizer में इस अवधारणा का समर्थन करने की आवश्यकता है। और इसलिए, 5.5 शाखा के भीतर रहने के लिए। इस धागे से पहला संस्करण, 5.5.0, लगभग चार साल पहले, अक्टूबर 2014 में आया था। तब से, 5.5 में कोई भी बड़ा परिवर्तन नहीं हुआ है। परियोजनाएँ जो पहले ही स्विच या तुरंत SObjectize-5.5 पर शुरू हो चुकी हैं, बिना किसी समस्या के 5.5 शाखा में नई रिलीज़ पर स्विच कर सकती हैं। इस समय इस संगतता को बनाए रखा जाना चाहिए।

सामान्य तौर पर, सब कुछ सरल है: आपको लेने और करने की आवश्यकता है।

क्या करना है यह स्पष्ट है

समस्या के पहले दृष्टिकोण के बाद, "रिकॉल संदेशों" के कार्यान्वयन के बारे में दो बातें स्पष्ट हो गईं।

संदेश प्रसंस्करण से पहले परमाणु ध्वज और उसका सत्यापन

सबसे पहले, यह स्पष्ट है कि वर्तमान SObjectizer-5.5 वास्तुकला के ढांचे के भीतर (और शायद और भी विश्व स्तर पर: SObjectizer -5 के सिद्धांतों के ढांचे के भीतर ही), डिस्पैचर अनुरोध कतारों से संदेशों को निकालना असंभव है, जहां संदेश प्राप्तकर्ताओं की प्रक्रिया तक इंतजार करते हैं। ऐसा करने की कोशिश करने से विषम डिस्पैचर्स के पूरे विचार को मार दिया जाएगा, जो कि उपयोगकर्ता भी अपने काम की बारीकियों के अनुसार कर सकते हैं (उदाहरण के लिए, यह एक )। इसके अलावा, 1: एन मोड में एक संदेश भेजने के मामले में, जहां एन बड़ा होगा, सभी कतार में भेजे गए संदेश के उदाहरण के लिए पॉइंटर्स की एक सूची रखना महंगा होगा।

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

तदनुसार, संदेश वापस बुलाने के लिए संदेश के अंदर परमाणु ध्वज के लिए एक विशेष मूल्य निर्धारित करना शामिल है।

प्रत्यावर्तनीय_हैंडल_ट <M> वस्तु

दूसरे, अब तक (?) यह स्पष्ट है कि एक संदेश भेजने के लिए, संदेश भेजने के सामान्य तरीकों का उपयोग नहीं किया जाना चाहिए, लेकिन कोड नाम Revocable_handle_t के तहत एक विशेष वस्तु।

एक रीवोकेबल संदेश भेजने के लिए, उपयोगकर्ता को रिवोकेबल_हैंडल_ट का एक इंस्टेंस बनाना होगा, और फिर इस इंस्टेंस पर सेंड मेथड को कॉल करना होगा। और यदि संदेश को वापस बुलाने की आवश्यकता है, तो यह रिवोक विधि का उपयोग करके किया जाता है। कुछ इस तरह:

 struct my_message {...}; ... so_5::revocable_handle_t<my_message> msg; //    . msg.send(target, //  . ... //    my_message. ); ... //   . msg.revoke(); 

अभी तक रिवोकेबल_हैंडल_टी के कार्यान्वयन का कोई स्पष्ट विवरण नहीं है, जो तब से आश्चर्यजनक नहीं है रिकॉल संदेशों के कार्य का तंत्र अभी तक चयनित नहीं हुआ है। लेकिन काम का सिद्धांत यह है कि Revocable_handle_t में एक स्मार्ट लिंक भेजे गए संदेश और इसके लिए परमाणु ध्वज को बचाया जाता है। निरस्त () विधि ध्वज मान को बदलने का प्रयास करती है। यदि यह सफल होता है, तो आदेश कतार से निकालने के बाद, संदेश को संसाधित नहीं किया जाएगा।

क्या इससे दोस्ती नहीं होगी

दुर्भाग्य से, कुछ चीजें हैं जिनके साथ याद करने वाले संदेश ठीक से लिंक नहीं किए जा सकते हैं। सिर्फ इसलिए कि हटाए गए संदेश उन कतारों में बने रहे जहां यह पहले ही आ चुका है।

message_limits

SObjectizer की इस तरह की एक महत्वपूर्ण विशेषता message_limits को ओवरलोड से एजेंटों की रक्षा के लिए डिज़ाइन किया गया है। Message_limits कतार में संदेशों की गिनती के आधार पर काम करते हैं। एक संदेश पंक्तिबद्ध किया - काउंटर बढ़ाया। लाइन से बाहर हो गया - कम हो गया।

क्योंकि जब कोई संदेश निरस्त किया जाता है, तो वह कतार में रहता है, तब संदेश की प्रतिक्रिया का संदेश प्रभावित नहीं करता है। इसलिए, यह पता चल सकता है कि कतार में एम टाइप के संदेशों की संख्या की सीमा है, लेकिन उन सभी को वापस बुला लिया गया है। वास्तव में, उनमें से एक भी संसाधित नहीं किया जाएगा। लेकिन टाइप M के एक नए संदेश की कतार लगाने से काम नहीं चलेगा, क्योंकि सीमा पार हो गई है।

स्थिति अच्छी नहीं है। लेकिन इससे कैसे बाहर निकला जाए? यह स्पष्ट नहीं है।

निश्चित कतार mchains

SObjectizer में, एक संदेश न केवल mbox को भेजा जा सकता है, बल्कि mchain को भी भेजा जा सकता है (यह CSP चैनल का हमारा एनालॉग है )। और mchains उनकी कतारों के लिए एक निश्चित आकार हो सकता है। फुल मचिन में एक निश्चित आकार के साथ मचिन के लिए एक नया संदेश डालने का प्रयास किसी तरह की प्रतिक्रिया का कारण होना चाहिए। उदाहरण के लिए, कतार में जगह छोड़ने का इंतजार। या सबसे पुराने संदेश को आगे बढ़ाने के लिए।

किसी संदेश को वापस बुलाने के मामले में, यह माचिन कतार के अंदर रहेगा। यह पता चला है कि संदेश की अब आवश्यकता नहीं है, लेकिन यह माचिन कतार में जगह लेता है। और नए संदेशों को माचिन में भेजने से रोकता है।

मैसेज_लिमिट्स के साथ भी वही खराब स्थिति। और फिर, यह स्पष्ट नहीं है कि यह कैसे तय किया जा सकता है।

क्या करना है यह स्पष्ट नहीं है

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

Revocable_t <M> के रूप में प्राप्त करने योग्य संदेश प्राप्त करें

पहला समाधान, जो दिखता है, सबसे पहले, संभव और, दूसरा, काफी व्यावहारिक है, एक विशेष आवरण का प्रस्ताव है Revocable_t <M>। जब उपयोगकर्ता Revocable_handle_t <M> के माध्यम से टाइप M का एक बदला हुआ संदेश भेजता है, तो यह वह संदेश M नहीं है जिसे भेजा गया है, बल्कि विशेष आवरण के अंदर संदेश M को Revocable_t <M> भेजा जाता है। और, तदनुसार, उपयोगकर्ता टाइप एम के संदेश को प्राप्त नहीं करेगा और संसाधित करेगा, लेकिन संदेश Revocable_t <M>। उदाहरण के लिए, इस तरह से:

 class processor : public so_5::agent_t { public: struct request { ... }; // ,    . void so_define_agent() override { //   . so_subscribe_self().event( //     ,    //   . [this](mhood_t< revocable_t<request> > cmd) { // ,      . cmd->try_handle([this](mhood_t<request> msg) { ... }); }); ... } ... }; 

Revocable_t <M> :: try_handle () विधि परमाणु ध्वज के मूल्य की जांच करती है और, यदि संदेश वापस नहीं लिया जाता है, तो उस पर दिए गए लंबो फ़ंक्शन को कॉल करता है। यदि संदेश वापस ले लिया जाता है, तो try_handle () कुछ नहीं करता है।

इस दृष्टिकोण के पेशेवरों और विपक्ष

मुख्य प्लस यह है कि इस यात्रा को आसानी से लागू किया जाता है (कम से कम अब तक ऐसा लगता है)। वास्तव में, Revocable_handle_t <M> और Revocable_t <M> SObjectizer में केवल एक सूक्ष्म ऐड-ऑन होगा।

SObjectizer इंटर्नल में हस्तक्षेप दोस्तों को रिवोकेबल_टी और mutable_msg बनाने के लिए आवश्यक हो सकता है। तथ्य यह है कि SObjectizer में अपरिवर्तनीय संदेशों की अवधारणा है (उन्हें 1: 1 मोड में और 1: N मोड दोनों में भेजा जा सकता है)। और परस्पर संदेशों की अवधारणा है जो केवल 1: 1 मोड में भेजी जा सकती है। इस मामले में, एक विशेष तरीके से एसओबीजेनाइजर उत्परिवर्तनीय_एमएसजी <एम> मार्कर का इलाज करता है और रन-टाइम पर संबंधित जांच करता है। Revocable_t <mutable_msg <M >> के मामले में, आपको इस निर्माण को mutable_msg <M> के रूप में व्यवहार करने के लिए SObjectizer को सिखाना होगा।

एक और प्लस यह है कि अतिरिक्त ओवरहेड (दोनों प्रत्यावर्तनीय संदेश के मेटाडेटा और परमाणु ध्वज के सत्यापन पर) केवल उन स्थानों पर होंगे जहां आप इसके बिना नहीं कर सकते। जहाँ रिकॉल संदेशों का उपयोग नहीं किया जाता है, वहाँ कोई अतिरिक्त ओवरहेड नहीं होगा।

लेकिन मुख्य माइनस वैचारिक है। इस दृष्टिकोण में, रीकोसेबल संदेशों का उपयोग करने का तथ्य प्रेषक (रिवोकेबल_हैंडल_टी <एम> का उपयोग करके) और प्राप्तकर्ता (रेवोकेबल_टी <एम> का उपयोग करके) दोनों को प्रभावित करता है। लेकिन प्राप्तकर्ता को यह जानने की जरूरत नहीं है कि उसे वापस बुलाए गए संदेश मिल रहे हैं। इसके अलावा, प्राप्तकर्ता के रूप में आपके पास एक रेडीमेड थर्ड-पार्टी एजेंट हो सकता है जो बगैर रिवोकेबल_टी <M> के लिखा जाता है।

इसके अलावा, वैचारिक प्रश्न इस तरह के संदेशों को अग्रेषित करने की संभावना के बारे में बने हुए हैं। लेकिन, पहले अनुमानों के अनुसार, इन मुद्दों का समाधान किया जाता है।

नियमित संदेशों के रूप में रिकॉल संदेशों को प्राप्त करें

दूसरा तरीका यह है कि केवल रिसीवर की तरफ टाइप M का संदेश देखें और न कि Revocable_handle_t <M> और revocable_t <M> के अस्तित्व का विचार रखें। यानी यदि प्रोसेसर को एक अनुरोध प्राप्त करना चाहिए, तो उसे केवल एक अनुरोध देखना चाहिए, बिना किसी अतिरिक्त आवरण के।

वास्तव में, कोई इस दृष्टिकोण में कुछ आवरण के बिना नहीं कर सकता है, लेकिन वे SObjectizer के अंदर छिपे रहेंगे और उपयोगकर्ता को उन्हें नहीं देखना चाहिए। एप्लिकेशन को कतार से पुनर्प्राप्त करने के बाद, SObjectizer खुद के लिए निर्धारित करेगा कि यह एक विशेष रूप से लिपटे बगावत संदेश है, संदेश की प्रासंगिकता के ध्वज की जांच करें, और संदेश का विस्तार करें यदि यह अभी भी प्रासंगिक है। फिर यह एजेंट को प्रसंस्करण के लिए एक संदेश भेजेगा जैसे कि यह एक नियमित संदेश था।

इस दृष्टिकोण के पेशेवरों और विपक्ष

इस दृष्टिकोण का मुख्य लाभ स्पष्ट है - संदेश प्राप्तकर्ता को पता नहीं है कि वह किन संदेशों के साथ काम करता है। यह संदेश भेजने वाले को किसी भी एजेंट के लिए संदेश को शांत करने की अनुमति देता है, यहां तक ​​कि उन जो अन्य डेवलपर्स द्वारा लिखे गए थे।

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

लेकिन मुख्य नुकसान इस दृष्टिकोण को लागू करने की जटिलता है। जिस पर कई कारकों को ध्यान में रखना होगा।

सबसे पहले, ओवरहेड। सब तरह की बातें।

मान लें कि आप एक संदेश के अंदर एक विशेष ध्वज बना सकते हैं जो इंगित करता है कि यह संदेश प्रतिसंहरणीय है या नहीं। और फिर प्रत्येक संदेश को संसाधित करने के लिए शुरू करने से पहले इस ध्वज की जांच करें। मोटे तौर पर, एक और अगर संदेश वितरण तंत्र में जोड़ा जाता है, जो प्रत्येक (!) संदेश को संसाधित करते समय काम करेगा।

मुझे यकीन है कि वास्तविक अनुप्रयोगों में इस पर नुकसान अगर ध्यान देने योग्य होगा। लेकिन सिंथेटिक बेंचमार्क में गिरावट जरूर दिखाई देगी। इसके अलावा, बेंचमार्क जितना अधिक अमूर्त होता है, वह उतना ही वास्तविक काम करता है, उतना ही वह डूब जाएगा। और यह एक विपणन दृष्टिकोण से बुरा है, क्योंकि ऐसे कई व्यक्ति हैं जो सिंथेटिक बेंचमार्क के संदर्भ में रूपरेखा के बारे में निष्कर्ष निकालते हैं। और वे इसे विशेष रूप से करते हैं: यह समझ में नहीं आता कि यह किस प्रकार का बेंचमार्क है, कि यह मूल रूप से दिखाता है कि यह किस हार्डवेयर पर काम करता है, लेकिन कुछ विशेष टूल के प्रदर्शन के साथ योग की तुलना दूसरे परिदृश्य में, दूसरे हार्डवेयर पर, आदि। , आदि

सामान्य तौर पर, चूंकि हम एक सार्वभौमिक ढांचा तैयार कर रहे हैं, जो कि जैसा कि यह पता चलता है, अमूर्त बेंचमार्क में अमूर्त संख्याओं से आंका जाता है, हम केवल एक समय के लिए एक फीचर को जोड़ने के कारण सभी संदेशों के वितरण तंत्र में प्रदर्शन का 5%, खोना नहीं चाहते हैं। समय-समय पर और सभी उपयोगकर्ताओं के लिए नहीं।

इसलिए, आपको यह सुनिश्चित करने की आवश्यकता है कि प्राप्तकर्ता को संदेश भेजते समय, SObjectizer समझता है कि जब आप संदेश को निकालते हैं, तो आपको इसे एक विशेष तरीके से संभालने की आवश्यकता होती है। सिद्धांत रूप में, जब एक संदेश किसी एजेंट को दिया जाता है, तो SObjectizer संदेश के साथ एक सूचक को एक फ़ंक्शन को संग्रहीत करता है जो संदेश को संसाधित करते समय उपयोग किया जाएगा। विभिन्न तरीकों से अतुल्यकालिक संदेशों और तुल्यकालिक अनुरोधों को संभालने के लिए अब इसकी आवश्यकता है। वास्तव में, यह है कि एजेंट को संबोधित संदेश के लिए अनुरोध कैसा दिखता है:

 struct execution_demand_t { //! Receiver of demand. agent_t * m_receiver; //! Optional message limit for that message. const message_limit::control_block_t * m_limit; //! ID of mbox. mbox_id_t m_mbox_id; //! Type of the message. std::type_index m_msg_type; //! Event incident. message_ref_t m_message_ref; //! Demand handler. demand_handler_pfn_t m_demand_handler; ... }; 

जहाँ माँग_हैंडलर_पफ़्न_ट एक नियमित फ़ंक्शन पॉइंटर है:

 typedef void (*demand_handler_pfn_t)( current_thread_id_t, execution_demand_t & ); 

संदेश वापस लेने के लिए विशेष रूप से प्रक्रिया करने के लिए समान तंत्र का उपयोग किया जा सकता है। यानी जब mbox एजेंट को संदेश भेजता है, तो एजेंट जानता है कि क्या एक अतुल्यकालिक संदेश या एक तुल्यकालिक अनुरोध भेजा जाता है। इसी तरह, एक एजेंट को एक विशेष तरीके से अतुल्यकालिक कॉलबैक संदेश दिया जा सकता है। और एजेंट संदेश के साथ, फ़ंक्शन के लिए एक सूचक को बचाएगा, जो जानता है कि इसे रद्द किए गए संदेशों को कैसे संभालना चाहिए।

सब कुछ ठीक लग रहा है, लेकिन दो बड़े "बट्स" हैं ... :(

सबसे पहले, मौजूदा mbox इंटरफ़ेस (अर्थात्, abstract_message_mbox_t वर्ग) को रिकॉल संदेश भेजने की कोई विधियाँ नहीं हैं। इसलिए इस इंटरफ़ेस को विस्तारित करने की आवश्यकता है। और इसलिए कि अन्य लोगों के mbox कार्यान्वयन, जो SObjectizer-5.5 से abstract_message_box_t से जुड़े हुए हैं (विशेष रूप से, mbox श्रृंखला so_5_extra में लागू नहीं हुई है और मैं उन्हें नहीं तोड़ना चाहता)।

दूसरे, संदेश न केवल mbox-s को भेजे जा सकते हैं, जिसके पीछे एजेंट छिपे होते हैं, लेकिन mchain-s को भी। जो सीएसपी चैनलों के हमारे समकक्ष हैं । और अब तक, एप्लिकेशन बिना किसी अतिरिक्त बिंदु के फ़ंक्शन के लिए झूठ बोल रहे थे। आवेदन कतार mchain के प्रत्येक तत्व में एक अतिरिक्त सूचक शुरू करने के लिए ... आप कर सकते हैं, निश्चित रूप से, लेकिन यह एक महंगी समाधान की तरह दिखता है। इसके अलावा, अब तक खुद मचिन कार्यान्वयन ने ऐसी स्थिति के लिए प्रदान नहीं किया है जिसमें निकाले गए संदेश को जांचना और संभवतः फेंकना आवश्यक है।

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

लेकिन लंबित संदेशों की गारंटी रद्द करने के बारे में क्या?

मुझे डर है कि तकनीकी समस्याओं के कारण मूल समस्या खो गई है। मान लीजिये कि वहाँ पर परिवर्तनशील संदेश हैं, तो लंबित / आवधिक संदेशों को कैसे रद्द किया जाएगा?

यहां, जैसा कि वे कहते हैं, विकल्प संभव हैं। उदाहरण के लिए, लंबित / आवधिक संदेशों के साथ काम करना Revocable_handle_t <M> कार्यक्षमता का हिस्सा हो सकता है:

 revocable_handle_t<my_mesage> msg; msg.send_delayed(target, 15s, ...); ... msg.revoke(); 

या आप Revocable_handle_t <M> के एक अतिरिक्त सहायक कक्षा रद्द करने योग्य_timer_t <M> पर बना सकते हैं, जो send_delayed / send_periodic विधियाँ प्रदान करेगा।

सफेद स्थान: तुल्यकालिक अनुरोध

SObjectizer-5 प्रोग्राम में संस्थाओं (mbox और mchain को संदेश भेजकर) के बीच न केवल अतुल्यकालिक बातचीत का समर्थन करता है, बल्कि request_value / request_future के माध्यम से सिंक्रोनस इंटरैक्शन भी करता है। यह सिंक्रोनस इंटरेक्शन केवल एजेंटों के लिए काम नहीं करता है। यानीआप केवल एक एजेंट को उसके mbox के माध्यम से एक तुल्यकालिक अनुरोध नहीं भेज सकते। मचिन्स के मामले में, आप सिंक्रोनस रिक्वेस्ट भी कर सकते हैं, उदाहरण के लिए, दूसरे वर्किंग थ्रेड पर, जिस पर माचिन के लिए रिसीव () या सलेक्ट () किया गया था।

इसलिए, यह अभी भी स्पष्ट नहीं है कि क्या इसे प्रत्यावर्तनीय संदेशों के साथ संयोजन में तुल्यकालिक अनुरोधों का उपयोग करने की अनुमति दी जानी चाहिए। एक ओर, शायद यह कुछ समझ में आता है। उदाहरण के लिए, यह दिख सकता है:

 revocable_handle_t<my_request> msg; auto f = msg.request_future<my_reply>(target, ...); ... if(some_condition) msg.revoke(); ... f.get(); //      revoke(). 

दूसरी ओर, अभी भी रिकॉल संदेशों के साथ बहुत सारे असंगत संदेश हैं, इसलिए समकालिक बातचीत के मुद्दे को बेहतर समय तक स्थगित कर दिया गया है।

चुनें, लेकिन सावधान रहें। लेकिन चुनें

तो समस्या की समझ है। इसे हल करने के लिए दो विकल्प हैं। जो इस समय संभव है। लेकिन वे उपयोगकर्ता को प्रदान की जाने वाली सुविधा के स्तर में बहुत भिन्न होते हैं, और इससे भी अधिक दृढ़ता से वे कार्यान्वयन की लागत में भिन्न होते हैं।

आपको इन दो विकल्पों में से चुनना होगा। या किसी और चीज के साथ आते हैं।

चुनने में क्या कठिनाई है?

कठिनाई यह है कि SObjectizer एक निःशुल्क ढांचा है। वह सीधे तौर पर हमें पैसा नहीं देता है। हम ऐसा करते हैं, जैसा वे कहते हैं, अपने लिए। इसलिए, विशुद्ध रूप से आर्थिक प्राथमिकताओं से, लागू करने के लिए एक सरल और तेज विकल्प अधिक लाभदायक है।

लेकिन, दूसरी तरफ, पैसे में सब कुछ नहीं मापा जाता है, और लंबे समय में, एक अच्छी तरह से बनाया गया उपकरण, जिनमें से विशेषताएं आम तौर पर एक-दूसरे से जुड़ी होती हैं, पैचवर्क से बने पैचवर्क से बेहतर होता है जो किसी भी तरह एक साथ चिपक जाते हैं। गुणवत्ता का मूल्यांकन उपयोगकर्ताओं और स्वयं दोनों द्वारा किया जाता है, जब हम बाद में अपने विकास के साथ होते हैं और इसमें नई सुविधाएँ जोड़ते हैं।

इसलिए, विकल्प, वास्तव में, अल्पकालिक लाभ और दीर्घकालिक संभावनाओं के बीच जाता है। सच है, आधुनिक दुनिया में, सी + + लंबी अवधि की संभावनाओं वाले उपकरण किसी तरह से धूमिल हैं। जिससे चुनाव और भी मुश्किल हो जाता है।

यह ऐसी स्थितियों में है जिसे आपको चुनना है। ध्यान से। लेकिन चुनें।

निष्कर्ष

इस लेख में हमने अपने ढांचे में नई विशेषताओं को डिजाइन करने और कार्यान्वित करने की प्रक्रिया को थोड़ा दिखाने की कोशिश की। इस तरह की प्रक्रिया हमारे साथ नियमित रूप से होती है। पहले अक्सर क्योंकि 2014-2016 में SObjectizer ने अधिक सक्रिय रूप से विकास किया। अब नए संस्करणों की रिलीज की गति कम हो गई है। जो उद्देश्यपूर्ण है, जिसमें कुछ भी तोड़ने के बिना नई कार्यक्षमता जोड़ना, प्रत्येक नए संस्करण के साथ अधिक कठिन हो जाता है।

मुझे उम्मीद है कि हमारे सामने पर्दे के पीछे देखना दिलचस्प था। आपका ध्यान के लिए धन्यवाद!