Qt में उचित थ्रेडिंग

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

यह लेख इस बात को व्यवस्थित करने का प्रयास है कि Qt "हुड के तहत" कैसे प्रवाह के साथ काम करता है और इस मॉडल की सीमाओं के साथ जुड़े कई अप्रभावी नुकसान के बारे में है।

मूल बातें
धागा आत्मीयता, आरंभीकरण, और उनकी सीमाएँ
मुख्य सूत्र, QCoreApplication और GUI
धागा सौंपना
निष्कर्ष

मूल बातें

आइए बुनियादी बातों से शुरू करें। Qt में, सिग्नल और स्लॉट्स को संभालने में सक्षम कोई भी ऑब्जेक्ट QObject क्लास के वंशज हैं। डिजाइन द्वारा ये वस्तुएं अजेय हैं और तार्किक रूप से कुछ व्यक्तिगत संस्थाओं का प्रतिनिधित्व करती हैं जो एक दूसरे के साथ "बात" करते हैं - कुछ घटनाओं पर प्रतिक्रिया करते हैं और खुद घटनाओं को उत्पन्न कर सकते हैं। दूसरे शब्दों में, Qt में QObject एक्टर्स पैटर्न को लागू करता है। यदि सही ढंग से कार्यान्वित किया जाता है, तो कोई भी Qt प्रोग्राम अनिवार्य रूप से QObjects के नेटवर्क से अधिक कुछ नहीं होता है, जो एक दूसरे के साथ बातचीत करते हैं, जिसमें सभी प्रोग्राम लॉजिक "रहता है"।

QObjects के एक सेट के अलावा, एक Qt प्रोग्राम में डेटा ऑब्जेक्ट शामिल हो सकते हैं। ये ऑब्जेक्ट सिग्नल उत्पन्न और प्राप्त नहीं कर सकते हैं, लेकिन कॉपी किए जा सकते हैं। उदाहरण के लिए, आप QStringList और QStringListModel की तुलना कर सकते हैं। उनमें से एक QObject है और प्रतिलिपि योग्य नहीं है, लेकिन UI ऑब्जेक्ट्स के साथ सीधे इंटरैक्ट कर सकता है, दूसरा डेटा के लिए एक नियमित प्रतिलिपि योग्य कंटेनर है। बदले में, डेटा वाली वस्तुओं को "क्यूटी मेटा-प्रकार" और अन्य सभी में विभाजित किया जाता है। उदाहरण के लिए, QStringList एक Qt मेटा-प्रकार है, लेकिन std :: list <std :: string> (अतिरिक्त इशारों के बिना) नहीं है। पूर्व को किसी भी Qt-shnom संदर्भ (संकेतों के माध्यम से प्रेषित, QVariant, आदि में झूठ बोलना) में इस्तेमाल किया जा सकता है, लेकिन इसके लिए एक विशेष पंजीकरण प्रक्रिया की आवश्यकता होती है और कक्षा में एक सार्वजनिक विध्वंसक, प्रतिलिपि निर्माता और डिफ़ॉल्ट निर्माता होना चाहिए। दूसरा मनमाना C ++ प्रकार है।

निर्बाध रूप से वास्तविक थ्रेड पर जाएं

तो, हमारे पास सशर्त "डेटा" है और एक सशर्त "कोड" है जो उनके साथ काम करता है। लेकिन वास्तव में इस कोड को कौन निष्पादित करेगा? Qt मॉडल में, इस प्रश्न का उत्तर स्पष्ट रूप से सेट किया गया है: प्रत्येक QObject को कड़ाई से कुछ क्यूथ्रेड धागे से बांधा गया है, जो वास्तव में, स्लॉट्स और इस ऑब्जेक्ट की अन्य घटनाओं की सेवा में लगा हुआ है। एक धागा एक बार में कई QObjects की सेवा दे सकता है, या किसी पर भी नहीं, लेकिन QObject में हमेशा माता-पिता का धागा होता है और यह हमेशा एक ही होता है। वास्तव में, हम मान सकते हैं कि प्रत्येक क्यूथ्रेड QObject के कुछ सेट का "मालिक" है। क्यूटी शब्दावली में, इसे थ्रेड एफिनिटी कहा जाता है। आइए स्पष्टता के लिए कल्पना करने की कोशिश करें:



प्रत्येक QThread के अंदर उन वस्तुओं को संबोधित संदेशों की एक कतार होती है, जो इस qhread "स्वामित्व" के लिए होती हैं। Qt मॉडल मानता है कि यदि हम एक QObject कुछ कार्रवाई करना चाहते हैं, तो हम इस QObject को एक QEvent संदेश "भेजेंगे":

QCoreApplication::postEvent(QObject *receiver, QEvent *event, int priority); 

इस थ्रेड-सुरक्षित कॉल में, Qt वह क्यूथ्रेड पाता है जो रिसीवर ऑब्जेक्ट से संबंधित होता है, इस धागे की संदेश कतार को QEvent लिखता है, और यदि आवश्यक हो तो इस थ्रेड को जागृत करता है। यह उम्मीद की जाती है कि इस बिंदु पर चल रहे कोड किसी बिंदु पर उसके बाद कतार से संदेश को पढ़ेंगे और इसी क्रिया को करेंगे। वास्तव में ऐसा होने के लिए, क्यूथ्रेड में कोड को QEventLoop ईवेंट लूप में प्रवेश करना चाहिए, उचित ऑब्जेक्ट का निर्माण करना चाहिए और इसे या तो निष्पादन () विधि या प्रोसेसएवेंट्स () विधि को कॉल करना होगा। पहला विकल्प एक अंतहीन संदेश प्रसंस्करण लूप में प्रवेश करता है (QEventLoop से पहले (छोड़ें) ईवेंट प्राप्त करता है), दूसरा उन संदेशों को संसाधित करने तक सीमित है जो पहले कतार में जमा हुए हैं।



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


इस तरह के चक्र में संसाधित "घटना" की अवधारणा में क्या शामिल है? सभी Qt कर्मचारियों के लिए प्रसिद्ध, "सिग्नल" सिर्फ एक विशेष उदाहरण है, QEvent :: MetaCall। ऐसा क्यूईवेंट फ़ंक्शन (स्लॉट) को पहचानने के लिए आवश्यक जानकारी के लिए एक पॉइंटर को संग्रहीत करता है जिसे कॉल करने की आवश्यकता होती है और इसके तर्क। हालांकि, क्यूटी में संकेतों के अलावा, लगभग सौ (!) अन्य घटनाएं हैं, जिनमें से एक दर्जन विशेष क्यूटी घटनाओं (चाइल्डएडेड, डीफ्रेडडेलीट, पेरेंटचेंज) के लिए आरक्षित हैं और बाकी ऑपरेटिंग सिस्टम के विभिन्न संदेशों के अनुरूप हैं।


यहाँ स्पष्ट अवहेलना में से एक यह है कि क्यूटी में, एक धारा, आम तौर पर बोलना, एक डिस्पैचर भी नहीं हो सकता है, और इसलिए एक भी EventLoop नहीं है। इस स्ट्रीम से संबंधित वस्तुएं उनके भेजे गए ईवेंट का जवाब नहीं देंगी। चूंकि क्वेथ्रेड :: रन () डिफॉल्ट कॉल्स के द्वारा किया जाता है :: एग्जीक्यूटिव (निष्पादन) जिसके अंदर मानक ईवेंटलोप सिर्फ लागू किया जाता है, जो अक्सर रनहार्ट के अपने स्वयं के संस्करण को निर्धारित करने का प्रयास करते हैं () क्वेथ्रेड से विरासत में अक्सर इस समस्या का सामना करते हैं। क्यूथ्रेड के लिए एक समान उपयोग का मामला सिद्धांत रूप में काफी मान्य है और यहां तक ​​कि दस्तावेज में भी इसकी सिफारिश की गई है, लेकिन यह ऊपर वर्णित क्यूटी में कोड को व्यवस्थित करने के सामान्य विचार के लिए काउंटर चलाता है और अक्सर काम नहीं करता है क्योंकि उपयोगकर्ता इसकी अपेक्षा करते हैं। इस मामले में एक सामान्य गलती यह है कि इस तरह के रिवाज़ को रोकने का प्रयास किया जाता है क्यूथ्रेड को बाहर निकल कर :: बाहर निकलें () या छोड़ दिया ()। ये दोनों कार्य QEventLoop को एक संदेश भेजते हैं, लेकिन यदि स्ट्रीम में कोई QEventLoop नहीं है, तो स्वाभाविक रूप से उन्हें संसाधित करने वाला कोई नहीं है। नतीजतन, अनुभवहीन उपयोगकर्ता "एक टूटे हुए वर्ग को ठीक करने" की कोशिश करने के लिए "वर्किंग" क्यूथ्रेड :: समाप्ति का उपयोग करने की कोशिश करना शुरू करते हैं, जो कि बिल्कुल असंभव है। ध्यान रखें - यदि आप रन () को फिर से परिभाषित करते हैं और मानक ईवेंट लूप का उपयोग नहीं करते हैं, तो आपको स्वयं थ्रेड से बाहर निकलने के लिए एक तंत्र प्रदान करना होगा - उदाहरण के लिए, इसके लिए विशेष रूप से जोड़े गए qhread :: requestInterruption () फ़ंक्शन का उपयोग करें। यह अधिक सही है, हालाँकि, यदि आप वास्तव में कुछ विशेष प्रकार के थ्रेड्स को लागू नहीं करने जा रहे हैं, तो क्यूथ्रेड से इनहेरिट नहीं कर सकते हैं या तो ऐसे स्क्रिप्ट के लिए विशेष रूप से बनाए गए QtConcurrent का उपयोग कर सकते हैं, या तर्क को QObject से विरासत में प्राप्त एक विशेष कार्यकर्ता में डाल सकते हैं, बाद वाले को मानक क्यूथ्रेड में रखें और प्रबंधित करें संकेतों का उपयोग करते हुए कार्यकर्ता।

धागा आत्मीयता, आरंभीकरण, और उनकी सीमाएँ

इसलिए, जैसा कि हमने पहले ही पता लगा लिया है, क्यूटी में प्रत्येक वस्तु कुछ धारा के लिए "संबंधित" है। उसी समय, एक तार्किक प्रश्न उठता है: किससे, वास्तव में, बिल्कुल? निम्नलिखित कथनों को Qt में स्वीकार किया जाता है:

1. किसी भी "माता-पिता" के सभी "बच्चे" हमेशा माता-पिता के समान ही रहते हैं

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

2. एक ऐसी वस्तु जिसका निर्माण के दौरान माता-पिता निर्दिष्ट नहीं है, वह उस धारा में रहती है जिसने इसे बनाया है

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

यदि आवश्यक हो तो धागा आत्मीयता को बदल दिया जा सकता है। QObject :: MoveToThread। नियम 1 के आधार पर, केवल शीर्ष-स्तरीय "माता-पिता" (जिसके लिए माता-पिता == अशक्त) को स्थानांतरित किया जा सकता है, किसी भी "बच्चे" को स्थानांतरित करने का प्रयास चुपचाप नजरअंदाज कर दिया जाएगा। जब ऊपरी-स्तरीय "मूल" चलता है, तो उसके सभी "बच्चे" भी एक नई धारा में चले जाएंगे। उत्सुकता से, मूव टूट्रेड (नल्ट्र्र) कॉल भी कानूनी है और "शून्य" धागा आत्मीयता के साथ एक ऑब्जेक्ट बनाने का एक तरीका है; ऐसी वस्तुओं को कोई संदेश नहीं मिल सकता है।

आप qhread :: currentThread () फ़ंक्शन के लिए कॉल के माध्यम से निष्पादन का "वर्तमान" धागा प्राप्त कर सकते हैं, वह धागा जिसके साथ ऑब्जेक्ट जुड़ा हुआ है - QObject के लिए कॉल के माध्यम से :: धागा ()

मुख्य सूत्र, QCoreApplication और GUI

सभी थ्रेड्स के बीच, क्यूटी निश्चित रूप से एक "मुख्य धागा" को सिंगल कर देगा, जो यूआई अनुप्रयोगों के मामले में भी जीयूआई थ्रेड बन जाता है। इस थ्रेड में QApplication ऑब्जेक्ट (QCoreApplication / QGuiApplication) रहता है जो ऑपरेटिंग सिस्टम के संदेशों के साथ काम करने के लिए मुख्य ईवेंट लूप ओरिएंटेड कार्य करता है। पिछले खंड से नियम नंबर 2 के आधार पर, व्यवहार में, "मुख्य" धागा वह होगा जो वास्तव में QApplication ऑब्जेक्ट बनाता है, और चूंकि कई ऑपरेटिंग सिस्टमों में "मुख्य धागा" का विशेष अर्थ है, प्रलेखन दृढ़ता से पूरे पूरे पहले ऑब्जेक्ट के साथ Qclication बनाने की सलाह देता है। क्यूटी प्रोग्राम और आवेदन शुरू करने के तुरंत बाद (== प्रक्रिया में पहले धागे के अंदर) करें। क्रमशः आवेदन के मुख्य धागे के लिए एक संकेतक प्राप्त करने के लिए, आप फॉर्म के निर्माण का उपयोग कर सकते हैं QCoreApplication :: उदाहरण () -> धागा ()। हालांकि, विशुद्ध रूप से तकनीकी रूप से, QApplication को गैर-मुख्य () स्ट्रीम पर भी लटका दिया जा सकता है , उदाहरण के लिए, यदि Qt इंटरफ़ेस कुछ प्रकार के प्लग-इन के अंदर बनाया गया है और कई मामलों में यह ठीक काम करेगा।

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

इस तथ्य के अलावा कि "मुख्य" धागा "पहला" है और इसमें मुख्य QCoreApplication इवेंट प्रोसेसिंग लूप शामिल है, Qt की एक और सीमा विशेषता यह है कि इस धागे में GUI से जुड़ी सभी वस्तुओं को "लाइव" होना चाहिए। यह आंशिक रूप से लिगेसी का परिणाम है: इस तथ्य के कारण कि कई ऑपरेटिंग सिस्टमों में GUI के साथ कोई भी ऑपरेशन केवल मुख्य थ्रेड में हो सकता है, Qt सभी ऑब्जेक्ट्स को "विगेट्स" और "नॉन-विजेट्स" में उपविभाजित करता है। विजेट-प्रकार की वस्तु केवल मुख्य धागे में रह सकती है, किसी अन्य में ऐसी वस्तु को "आउटवे" करने का प्रयास स्वचालित रूप से भड़क जाएगा। इसके आधार पर, यहां तक ​​कि एक विशेष QObject :: isWidgetType () विधि भी है जो ऐसी वस्तुओं के साथ काम करने के यांत्रिकी में गहरे आंतरिक अंतर को दर्शाती है। लेकिन यह दिलचस्प है कि बहुत नए QtQuick में, जहाँ उन्होंने isWidgetType के साथ बैसाखी से दूर जाने की कोशिश की, वही समस्या बनी रही

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

धागा सौंपना

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

लेकिन जैसा कि मैंने पहले ही पिछले अध्याय में उल्लेख किया है, क्योंकि हमारे पास एक स्ट्रीम है जो डेटा (एक फ्रंट) बनाता है और एक स्ट्रीम जो इसे (पीछे) पढ़ता है, हमें किसी तरह उन्हें सिंक्रनाइज़ करने की आवश्यकता है। क्यूटी में यह सिंक्रनाइज़ेशन ताले द्वारा किया जाता है। वह धारा जहां सामने का जीवन अस्थायी रूप से निलंबित है, उसके बाद एक विशेष फ़ंक्शन कॉल (QQuickItem :: updatePaintNode (), QQuickFramebufferObject :: Renderer :: सिंक्रोनाइज़ ()) जिसका एकमात्र कार्य राज्य को सामने से सामने की ओर देखने के लिए प्रासंगिक वस्तु की प्रतिलिपि बनाना है। "। इस मामले में, इस तरह के फ़ंक्शन का कॉल रेंडरिंग थ्रेड के अंदर होता है , लेकिन इस तथ्य के कारण कि थ्रेड जहां ऑब्जेक्ट इस समय रहता है, उपयोगकर्ता स्वतंत्र रूप से ऑब्जेक्ट के डेटा के साथ काम कर सकता है जैसे कि यह "हमेशा की तरह" हुआ, स्ट्रीम के अंदर जो ऑब्जेक्ट का है।

क्या सब कुछ ठीक है, क्या सब कुछ ठीक है? दुर्भाग्य से, नहीं, और काफी स्पष्ट क्षण यहां से शुरू होते हैं। यदि हम प्रत्येक वस्तु के लिए व्यक्तिगत रूप से ताला लगाते हैं, तो यह धीमी गति से होगा क्योंकि रेंडरिंग थ्रेड को तब तक इंतजार करने के लिए मजबूर किया जाएगा जब तक कि ये ऑब्जेक्ट्स अपने ईवेंट को संसाधित नहीं करते। "हैंग" स्ट्रीम जहां वस्तु रहती है "हैंग" और रेंडरिंग। इसके अलावा, एक "desync" तब संभव हो जाएगा जब दो वस्तुओं को एक साथ बदल दिया जाएगा, एक को फ्रेम एन में खींचा जाएगा और दूसरे को केवल फ्रेम एन + 1 में खींचा जाएगा। केवल एक बार और सभी वस्तुओं के लिए केवल एक ही बार ताला लेना बेहतर होगा, जब हम सुनिश्चित हों कि यह ताला सफल होगा।

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



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

और अब, अफसोस, मरहम में एक मक्खी: हालांकि अलग-अलग QQuickWindow सैद्धांतिक रूप से विभिन्न धाराओं में रह सकते हैं, व्यवहार में इसके लिए उन्हें ऑपरेटिंग सिस्टम से सटीक संदेश भेजने की आवश्यकता होती है और Qt में आज इसे लागू नहीं किया गया है। Qt 5.13 में, उदाहरण के लिए, QCoreApplication SendEvent के माध्यम से QQuickWindow के साथ संचार करने की कोशिश करता है, जिसके लिए रिसीवर और भेजने वाले पक्ष को एक ही थ्रेड में होना चाहिए (पोस्टईवेंट के बजाय जो थ्रेड को अलग करने की अनुमति देता है)। इसलिए, व्यवहार में, QQuickWindow केवल GUI थ्रेड में सही ढंग से काम करता है, और परिणामस्वरूप, सभी QtQuick ऑब्जेक्ट एक ही स्थान पर रहते हैं। परिणामस्वरूप, रेंडरिंग थ्रेड की उपस्थिति के बावजूद, उपयोगकर्ता के लिए उपलब्ध लगभग सभी GUI- संबंधित ऑब्जेक्ट अभी भी उसी GUI थ्रेड में रहते हैं। शायद यह Qt 6 में बदल जाएगा।

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

निष्कर्ष

क्यूटी एक विशाल और जटिल ढांचा है, और इसमें थ्रेड्स के साथ काम करना इस जटिलता का हिस्सा है। लेकिन यह बहुत सावधानी से, तार्किक और सक्षम रूप से डिजाइन किया गया था, इसलिए जब Qt में प्रवाह के साथ कई प्रमुख विचारों को समझते हैं, तो गलतियों के साथ काम करना काफी सरल है।

मुझे आपको मुख्य बिंदुओं को फिर से याद दिलाना है;

• प्रत्येक ऑब्जेक्ट में एक धागा होता है जो इसे मालिक करता है, ऑब्जेक्ट के साथ होने वाली सभी घटनाओं के संचालकों को निष्पादित करता है, जिसमें कतारबद्ध संकेतों को संसाधित करना शामिल है
• यदि थ्रेड "ऑब्जेक्ट" का मालिक क्यूटी ईवेंट लूप को निष्पादित नहीं करता है, तो इससे संबंधित वस्तुओं को कोई संदेश नहीं मिलेगा और थ्रेड स्वयं इसे बाहर निकलने का प्रयास करने का जवाब नहीं देगा ()
• माता-पिता और वंशज हमेशा एक ही धारा में रहते हैं। केवल शीर्ष-स्तरीय माता-पिता को स्ट्रीम से स्ट्रीम में स्थानांतरित किया जा सकता है। इस नियम के उल्लंघन के परिणामस्वरूप सेटपेंट या मूवऑट्रेड्रेड ऑपरेशन की मूक विफलता हो सकती है
• एक ऑब्जेक्ट जिसका माता-पिता निर्दिष्ट नहीं है, वह उस ऑब्जेक्ट की संपत्ति बन जाता है जिसे इस ऑब्जेक्ट ने बनाया था।
• सभी GUI ऑब्जेक्ट जो रेंडरिंग बैक-एंड को छोड़कर GUI स्ट्रीम में रहना चाहिए
• GUI थ्रेड वह है जिसमें QApplication ऑब्जेक्ट बनाया गया था

मुझे उम्मीद है कि यह Qt को अधिक कुशलता से उपयोग करने में मदद करेगा और इसके बहु-थ्रेडेड मॉडल से जुड़ी गलतियाँ नहीं करेगा।