फाइटलॉक: फाइटिंग कॉलबैक पैटर्न

गतिरोध की स्थिति

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

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

गतिरोध का एक क्लासिक उदाहरण: पहला धागा (ए) म्यूटेक्स एम 1 और फिर म्यूटेक्स एम 2 को कैप्चर करता है। दूसरा धागा (बी) एम 2 म्यूटेक्स को कैप्चर करता है, और उसके बाद, एम 1 म्यूटेक्स। इन दोनों धाराओं का आपसी अवरोध निम्न प्रकार से हो सकता है: धारा A कैप्चर M1, स्ट्रीम B कैप्चर M2, जिसके बाद दोनों धाराएं "डूम" हैं: न तो A, M2 को पकड़ सकता है, और न ही धागा B M1 को पकड़ सकता है; म्यूटेक्स को पकड़ने के प्रयास दोनों धागे को अवरुद्ध करेंगे।

वर्णित पारस्परिक लॉकिंग केवल तभी होगी जब दोनों थ्रेड्स के पास एक म्यूटेक्स को पकड़ने का समय होगा। अन्यथा, थ्रेड्स निष्पादित करना जारी रखेंगे।

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

एक वास्तविक प्रणाली में सामान्य स्थिति

ऊपर वर्णित गतिरोध की घटना के विशेष मामलों में से एक इस प्रकार है:

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

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

वर्णित चित्र में कुछ स्पर्श जोड़ने के लिए यह पर्याप्त है (जटिल प्रणालियों में ऐसा ही होता है):

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

वह सब है। यह एक ऐसी स्थिति बन गई जिसमें गतिरोध संभव है। यह 100% मामलों में नहीं होगा (केवल एक म्यूटेक्स को पकड़ने के लिए भाग लेने वाले प्रत्येक थ्रेड के लिए एक निश्चित गतिशीलता आवश्यक है), और यह इस तरह की त्रुटियों के लिए खोज को जटिल करता है।

इस समस्या को हल करने के दो तरीके हैं।

विधि 1: लॉक ऑर्डर बदलें

वर्कर ऑब्जेक्ट अपने आंतरिक म्यूटेक्स को लॉक करने और अनलॉक करने के लिए अलग-अलग फ़ंक्शन प्रदान करेगा, और उपभोक्ता निम्नानुसार पंजीकरण करेगा:

1. पहले (अग्रिम में), वर्कर ऑब्जेक्ट के आंतरिक म्यूटेक्स को लॉक किया जाएगा।
2. उसके बाद, उपभोक्ता म्यूटेक्स एम पर कब्जा करने की आवश्यकता वाले कार्यों का प्रदर्शन करेगा।
3. उपभोक्ता श्रमिक वस्तु के साथ पंजीकरण करेगा; कार्यकर्ता ऑब्जेक्ट के अंदर आंतरिक म्यूटेक्स पर कब्जा नहीं किया जाता है।

इस विधि के नुकसान स्पष्ट हैं:

• प्रत्येक उपभोक्ता पर वर्कर ऑब्जेक्ट के साथ काम करने से पहले प्रारंभिक क्रियाओं का बोझ होता है; प्रोग्रामर की ओर से त्रुटि की संभावना बढ़ जाती है;
• यह हमेशा संभव नहीं होता है: क्या होगा यदि म्यूटेक्स एम एक पॉइंटर को किसी कार्यकर्ता वस्तु तक सुरक्षित पहुंच प्रदान करता है?
• "हिम्मत बाहर है" बस बदसूरत है।

विधि 2: उपभोक्ताओं को डेटा संचारित करते समय म्यूटेक्स को ब्लॉक न करें

यह विधि आशाजनक लगती है: यदि उपभोक्ताओं के आंतरिक प्रवाह से डेटा का स्थानांतरण उपभोक्ताओं को म्यूटेक्स के साथ होता है जो अवरुद्ध नहीं हैं, तो यह श्रमिक ऑब्जेक्ट के साथ काम करते समय भविष्य के सभी संभावित अवरोधों को ठीक कर देगा।

जब म्यूटेक्स को कैप्चर नहीं किया जाता है तो केवल कॉलबैक क्यों न करें? क्योंकि वर्कर ऑब्जेक्ट स्ट्रीम पंजीकृत उपभोक्ताओं की सूची से गुजरना चाहिए और प्रत्येक उपभोक्ता के इंटरफ़ेस फ़ंक्शन को कॉल करना चाहिए। यदि इस चक्र के दौरान सूची को म्यूटेक्स और सूची की सामग्री द्वारा संरक्षित नहीं किया गया है, तो यह संभावना है कि प्रोग्राम गलत मेमोरी एक्सेस के कारण लूप या क्रैश होगा।

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

इस प्रकार, हम लगभग निर्णय पर आ गए:

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

यहाँ टर्नकी समाधान है। इसके कार्यान्वयन के लिए, एक और सिंक्रोनाइज़ेशन ऑब्जेक्ट की आवश्यकता है - एक "कंडीशन वेरिएबल" (अंग्रेजी कंडीशन वेरिएबल):

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

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

Qt लाइब्रेरी सिंक्रोनाइज़ेशन टूल्स का उपयोग करके कार्यान्वयन

हैडर फ़ाइल:

class ICallback { public: virtual void dataReady(QByteArray data) = 0; }; class Worker : public QThread { public: Worker(); void registerCallback(ICallback *callback); void unregisterCallback(ICallback *callback); protected: virtual void run(); private: QMutex _mutex; QWaitCondition _wait; bool _callingNow; QLinkedList<ICallback *> _callbacks; }; 

कार्यान्वयन:

 Worker::Worker() : QThread(), _mutex(QMutex::NonRecursive), _callingNow(false) { ... } void Worker::registerCallback(ICallback *callback) { QMutexLocker locker(&_mutex); _callbacks.append(callback); } void Worker::unregisterCallback(ICallback *callback) { QMutexLocker locker(&_mutex); _callbacks.removeOne(callback); if(QThread::currentThread()!=this) { while(_callingNow) _wait.wait(&_mutex); } } void Worker::run() { while(...) { QByteArray data; ... QLinkedList<ICallback *> callbacksCopy; _mutex.lock(); _callingNow=true; callbacksCopy=_callbacks; _mutex.unlock(); for(QLinkedList<Callback *>::const_iterator it=callbacksCopy.begin(); it!=callbacksCopy.end(); ++it) { (*it)->dataReady(data); } _mutex.lock(); _callingNow=false; _wait.wakeAll(); _mutex.unlock(); } }