वर्कफ़्लो प्रबंधन: सिंक्रोनाइज़ेशन चैनल

एक विशिष्ट अनुप्रयोग की वास्तुकला की कल्पना करें:

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

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

ऐसा लगता है, इतनी सरल स्थिति में कोई कैसे गलती कर सकता है?

कई मुद्दों का समाधान

जब कार्यक्रम में एक अतिरिक्त धागा दिखाई देता है, तो थ्रेड्स के बीच बातचीत की समस्या तुरंत उत्पन्न होती है। यहां तक ​​कि अगर धारा कुछ भी नहीं करती है और किसी के साथ संवाद नहीं करती है, तो हमेशा धारा के सही ठहराव की समस्या होती है।

यहां तक ​​कि जब थ्रेड्स पर उच्च-स्तरीय आवरण कक्षाओं के साथ काम करते हैं, तो कुछ गलत करना आसान होता है यदि आप थ्रेड्स के साथ काम करने के सही तरीके को पूरी तरह से नहीं समझते हैं। इसलिए, इस लेख में हम WinAPI स्तर पर थ्रेड्स के साथ काम करने के बारे में बात करेंगे।

और इसलिए, हमारे उदाहरण पर वापस जाएं।

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

दो मुख्य अधिसूचना विधियाँ अतुल्यकालिक और तुल्यकालिक हैं।

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

सिंक्रोनस विधि - वर्कफ़्लो समकालिक कॉल (SendMessage) की अपनी स्थिति को सूचित करता है, इस तरह के कॉल के प्रसंस्करण के पूरा होने की प्रतीक्षा कर रहा है।
यह विधि इस बात में सुविधाजनक है कि संदेश प्रक्रिया के समय कार्यकर्ता सूत्र, पहले से ज्ञात अवस्था में है। अत्यधिक सिंक्रनाइज़ेशन की कोई आवश्यकता नहीं है।

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

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

नुकसान: SendMessage + स्ट्रीम रोकें

जब मैं एक वर्कफ़्लो देखता हूं, तो मुझे तुरंत आश्चर्य होता है कि यह GUI के साथ कैसे इंटरैक्ट करता है और एक ही समय में इसे कैसे रोका जाता है।

कार्यकर्ता थ्रेड को सीधे या अप्रत्यक्ष रूप से GUI थ्रेड पर SendMessage अवरोधन फ़ंक्शन कहता है तो सावधान रहें। उदाहरण के लिए, WinAPI, यह पूरी तरह से हानिरहित कुछ हो सकता है, उदाहरण के लिए, सेटटेक्स्ट को किसी प्रकार का कॉल, जिसे आंतरिक रूप से SendMessage WM_SETTEXT कहते हैं। इस मामले में, आपको विशेष रूप से सावधान रहने की जरूरत है जब बटन क्लिक स्ट्रीम को रोकने की कोशिश हैंडलर और आवेदन बंद करते समय (यदि जीयूआई स्ट्रीम आवेदन की मुख्य धारा है)। यह पूरी तरह से स्पष्ट नहीं है, मैं आगे समझाने की कोशिश करूंगा।

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

// INFINITE ,  -       ,     WaitForSingleObject(hThread, INFINITE); 

यदि ऐसा नहीं किया जाता है, तो अप्रत्याशित परिणाम संभव हैं (कार्यक्रम फ्रीज और क्रैश)।
खासतौर पर अगर स्ट्रीम डायनेमिकली कनेक्टेड लाइब्रेरी के अंदर हो, जिसे वहीं अनलोड किया जाना चाहिए।

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

दूसरी आर्किटेक्चरल समस्या यह है कि अगर वर्कफ़्लो सीधे GUI कोड को कॉल करता है, तो आपको सिंक्रोनाइज़ेशन का ध्यान रखना होगा। स्ट्रीम के सिंक्रनाइज़ेशन को पूरे प्रोग्राम में स्मियर किया जाता है।

इन समस्याओं का समाधान

इंजन इंटरफ़ेस के अंदर वर्कफ़्लो अलग-थलग होना चाहिए।

COM सिंगल-थ्रेडेड अपार्टमेंट के सिद्धांत के अनुसार, इंजन से सभी सूचनाएं समकालिक रूप से और क्लाइंट स्ट्रीम के संदर्भ में आनी चाहिए।

कॉल समकालिक और पारदर्शी रूप से होने चाहिए: वर्कर थ्रेड कुछ फ़ंक्शन को कॉल करता है जो नियंत्रण को वापस नहीं करता है जब तक कि जीयूआई थ्रेड इस कॉल को संसाधित नहीं करता है।
लेकिन एक ही समय में, वर्कफ़्लो को पूरा करने में सक्षम होना चाहिए, यहां तक ​​कि ऐसे फ़ंक्शन को कॉल करने के समय भी।

नतीजतन, जीयूआई के लिए इंजन इंटरफ़ेस एकल-थ्रेडेड होगा, जो इस तरह के इंजन के साथ काम को बहुत सरल करेगा।

C ++ में कार्यान्वयन और उदाहरण के भिन्न रूप

इस व्यवहार को कार्यान्वित करने के लिए, आप एक पुन: प्रयोज्य वस्तु बना सकते हैं जो GUI कोड लागू करते समय थ्रेड्स के संदर्भ को बदल देगा।

मैंने इस तरह के ऑब्जेक्ट को कहा - एक सिंक्रनाइज़ेशन चैनल।

और इसलिए, हम कुछ प्रकार के सिंक्रनाइज़ेशन चैनल बनाते हैं, जिसकी मदद से इंजन वर्कफ़्लो जीयूआई द्वारा लागू कॉलबैक फ़ंक्शन को कॉल करेगा।

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

 class IEngineEvents { public: virtual void OnProgress(int progress) = 0; ... }; //-  ... IEngineEvents* listener; //  ,  GUI syncChannel.Execute(boost::bind(&IEngineEvents::OnProgress, listener, 30)); 

एक्सक्यूट फ़ंक्शन, जैसा कि पहले उल्लेख किया गया है, समकालिक है - यह तब तक समाप्त नहीं होता है जब तक कॉलबैक फ़ंक्शन पूरा नहीं होता है। नीचे वर्णित अपवाद को छोड़कर।

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

थ्रेड संदर्भ को स्विच करने के लिए, उदाहरण मानक Win32 थ्रेड संदेश कतार और PostThreadMessage फ़ंक्शन का उपयोग करता है।

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

यह कार्यान्वयन ProcessMessage फ़ंक्शन को मानता है, जिसे विंडो संदेश प्रसंस्करण चक्र या विंडो प्रक्रिया से बुलाया जाना चाहिए। इस तरह के फ़ंक्शन के बिना कार्यान्वयन भी संभव है, उदाहरण के लिए, एक चैनल खुद के लिए एक अदृश्य विंडो बना सकता है, और सभी संदेशों को अंदर संसाधित कर सकता है। इसके अलावा, सिद्धांत में विंडो संदेशों का उपयोग किए बिना कार्यान्वयन संभव है।

मैं यह भी कहना चाहूंगा कि उदाहरण केवल मार्गदर्शन के लिए है, और एक तैयार समाधान नहीं है।

 // SyncChannel.h class CSyncChannel { public: typedef boost::function<void()> CCallback; public: CSyncChannel(void); ~CSyncChannel(void); public: bool Create(DWORD clientThreadId); void Close(); bool Execute(CCallback callback); bool ProcessMessage(MSG msg); private: DWORD m_clientThreadId; CCallback m_callback; HANDLE m_deliveredEvent; volatile bool m_closeFlag; }; 

 // SyncChannel.cpp UINT WM_SYNC_CHANNEL_COMMAND = WM_APP + 500; CSyncChannel::CSyncChannel(void) : m_closeFlag(true) {} CSyncChannel::~CSyncChannel(void) {} bool CSyncChannel::Create(DWORD clientThreadId) { if (!m_closeFlag) { return false; } m_clientThreadId = clientThreadId; m_deliveredEvent = CreateEvent(NULL, TRUE, FALSE, NULL); if (!m_deliveredEvent) { return false; } m_closeFlag = false; return true; } void CSyncChannel::Close() { m_closeFlag = true; if (m_deliveredEvent) { CloseHandle(m_deliveredEvent); m_deliveredEvent = NULL; } } bool CSyncChannel::Execute(CCallback callback) { //        . //   ,        . //   Pause(),     // -    , //        "pause pending" if (m_closeFlag) { return false; } if (GetCurrentThreadId() == m_clientThreadId) { //    -   , //      ,    . //      ,        , //       -     . callback(); } else { //  Execute     , //        , //        . //      , //       . //      ,   , //      , //     . m_callback = callback; //     ,    //      ,     ResetEvent(m_deliveredEvent); //     ,   //    . //       ,  , //       CSyncChannel::ProcessMessage() if (!PostThreadMessage(m_clientThreadId, WM_SYNC_CHANNEL_COMMAND, NULL, NULL)) { return false; } // ,      CSyncChannel::ProcessMessage(), //     m_deliveredEvent, //       m_closeFlag //    m_closeFlag    //   WaitForMultipleObjects,      , //       . DWORD waitResult = WAIT_TIMEOUT; while (waitResult == WAIT_TIMEOUT && !m_closeFlag) { waitResult = WaitForSingleObject(m_deliveredEvent, 100); } if (waitResult != WAIT_OBJECT_0) { //      ,       return false; } } //          return true; } bool CSyncChannel::ProcessMessage(MSG msg) { //        if (msg.message != WM_SYNC_CHANNEL_COMMAND) { //         , //     return false; } if (!m_closeFlag) { //      , //         m_callback(); //   ,   . //       SetEvent(m_deliveredEvent); } return true; } 

CSyncChannel वर्ग का उपयोग करने के एक उदाहरण के लिए, निम्न आलेख देखें - वर्कफ़्लो का आयोजन: इंजन राज्य का प्रबंधन ।