थ्रेड कंसीलर सी ++ 11, इसकी बाइक टेक्नोलॉजी (Apple) जीसीडी

प्रविष्टि

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

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

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

ऐसा करने के लिए, मुझे निम्नलिखित C ++ 11 नवाचारों की आवश्यकता है - std :: function, varadic टेम्पलेट्स और निश्चित रूप से std :: thread के साथ काम करते हैं। (std :: shared_ptr का उपयोग केवल आत्म-आराम के लिए किया जाता है)। बेशक, एक और लक्ष्य जो मैंने खुद के लिए निर्धारित किया है वह है क्रॉस-प्लेटफॉर्म। और मुझे बहुत निराशा हुई जब मुझे पता चला कि Microsoft कंपाइलर, जिसे वीएस 2012 में बंडल किया गया था, ने वैरेडिक टेम्प्लेट का समर्थन नहीं किया। लेकिन स्टैकओवरफ़्लो का थोड़ा अध्ययन करने पर, मैंने देखा कि यह समस्या वैकल्पिक विज़ुअल सी ++ नवंबर 2012 सीटीपी पैकेज को स्थापित करके भी हल की गई थी।

कार्यान्वयन

जैसा कि मैंने पहले ही उल्लेख किया है, यह विचार थ्रेड पूल पैटर्न पर आधारित है। डिजाइन के दौरान, "gcdpp_t_task" के दो वर्गों को प्रतिष्ठित किया गया था, जो कि अपने आप में निष्पादन योग्य कार्य और gcdpp_t_queue - कतार संचय कार्यों को एकत्र करता है।

template<class FUCTION, class... ARGS> class gcdpp_t_task { protected: FUCTION m_function; std::tuple<ARGS...> m_args; public: gcdpp_t_task(FUCTION _function, ARGS... _args) { m_function = _function; m_args = std::make_tuple(_args...); }; ~gcdpp_t_task(void) { }; void execute(void) { apply(m_function, m_args); }; }; 

जैसा कि हम देख सकते हैं, यह वर्ग टेम्पलेट है। और यह हमारे लिए एक समस्या पैदा करता है - हम कार्यों को एक कतार में कैसे स्टोर कर सकते हैं, अगर वे विभिन्न प्रकार के हैं?

एक बार, मुझे आश्चर्य है कि C ++ में अभी भी इंटरफेस / प्रोटोकॉल के पूर्ण-पूर्ण कार्यान्वयन का अभाव क्यों है। आखिरकार, अमूर्तता से प्रोग्रामिंग का सिद्धांत कार्यान्वयन से अधिक प्रभावी है। ठीक है, कुछ भी नहीं, आप एक सार वर्ग बना सकते हैं।

 class gcdpp_t_i_task { private: protected: public: gcdpp_t_i_task(void) { }; virtual ~gcdpp_t_i_task(void) { }; virtual void execute(void) { assert(false); }; }; 

अब, टास्क एब्सट्रैक्शन से हमारी टास्क क्लास विरासत में मिली, हम आसानी से सब कुछ एक कतार में रख सकते हैं।

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

 template<unsigned int NUM> struct apply_ { template<typename... F_ARGS, typename... T_ARGS, typename... ARGS> static void apply(std::function<void(F_ARGS... args)> _function, std::tuple<T_ARGS...> const& _targs, ARGS... args) { apply_<NUM-1>::apply(_function, _targs, std::get<NUM-1>(_targs), args...); } }; template<> struct apply_<0> { template<typename... F_ARGS, typename... T_ARGS, typename... ARGS> static void apply(std::function<void(F_ARGS... args)> _function, std::tuple<T_ARGS...> const&, ARGS... args) { _function(args...); } }; template<typename... F_ARGS, typename... T_ARGS> void apply(std::function<void(F_ARGS... _fargs)> _function, std::tuple<T_ARGS...> const& _targs) { apply_<sizeof...(T_ARGS)>::apply(_function, _targs); } 

खैर, ऐसा लगता है कि सब कुछ पारदर्शी और स्पष्ट हो गया है। अब यह प्राथमिकताओं के साथ "थ्रेड पूल" को व्यवस्थित करना है।

  class gcdpp_t_queue { private: protected: std::mutex m_mutex; std::thread m_thread; bool m_running; void _Thread(void); public: gcdpp_t_queue(const std::string& _guid); ~gcdpp_t_queue(void); void append_task(std::shared_ptr<gcdpp_t_i_task> _task); }; 

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

और अब सबसे महत्वपूर्ण बात यह है कि सभी को कम या ज्यादा कामकाजी रूप में व्यवस्थित करना है।

 class gcdpp_impl { private: protected: friend void gcdpp_dispatch_init_main_queue(void); friend void gcdpp_dispatch_update_main_queue(void); friend std::shared_ptr<gcdpp_t_queue> gcdpp_dispatch_get_global_queue(gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY _priority); friend std::shared_ptr<gcdpp_t_main_queue> gcdpp_dispatch_get_main_queue(void); template<class... ARGS> friend void gcdpp_dispatch_async(std::shared_ptr<gcdpp_t_main_queue> _queue, std::function<void(ARGS... args)> _function, ARGS... args); std::shared_ptr<gcdpp_t_main_queue> m_mainQueue; std::shared_ptr<gcdpp_t_queue> m_poolQueue[gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY_MAX]; static std::shared_ptr<gcdpp_impl> instance(void); std::shared_ptr<gcdpp_t_queue> gcdpp_dispatch_get_global_queue(gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY _priority); std::shared_ptr<gcdpp_t_main_queue> gcdpp_dispatch_get_main_queue(void); template<class... ARGS> void gcdpp_dispatch_async(std::shared_ptr<gcdpp_t_main_queue> _queue, std::function<void(ARGS... args)> _function, ARGS... args); public: gcdpp_impl(void); ~gcdpp_impl(void); }; 

क्लास gcdpp_impl - एक सिंगलटन है और बाहरी प्रभावों से पूरी तरह से घिरा हुआ है। इसमें 3 टास्क पूल (प्राथमिकताओं के साथ, जबकि प्राथमिकताएं स्टब्स द्वारा लागू की जाती हैं), और मुख्य थ्रेड पर कार्यों को निष्पादित करने के लिए एक पूल होता है। कक्षा में 5 मित्र कार्य भी होते हैं। फ़ंक्शन gcdpp_dispatch_init_main_queue और gcdpp_dispatch_update_main_queue परजीवी हैं। बस अब मैं उन्हें काटने के लिए एक भयावह योजना विकसित कर रहा हूं। gcdpp_dispatch_update_main_queue - मुख्य थ्रेड पर कार्य प्रसंस्करण कार्य ... और मैं वास्तव में उपयोगकर्ता को इस फ़ंक्शन को उसके रन लूप में प्लग करने से बचाना चाहता हूं।

बाकी कार्यों के साथ, सब कुछ पारदर्शी लगता है:

gcdpp_dispatch_get_global_queue - प्राथमिकता कतार प्राप्त करें
gcdpp_dispatch_get_main_queue - मुख्य धागे पर एक कतार प्राप्त करें
gcdpp_dispatch_async - एक विशिष्ट थ्रेड में एक विशिष्ट थ्रेड में एक आस्थगित कॉल के लिए एक कतार ऑपरेशन डालता है।

आवेदन

और यह सब क्यों आवश्यक है?
मैं कई परीक्षणों पर इस कार्यान्वयन के लाभ को दिखाने की कोशिश करूंगा:

 std::function<void(int, float, std::string)> function = [](int a, float b, const std::string& c) { std::cout<<<<a<<b<<c<<std::endl; }; gcdpp::gcdpp_dispatch_async<int, float, std::string>(gcdpp::gcdpp_dispatch_get_global_queue(gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY_HIGH), function, 1, 2.0f, "Hello World"); 

इस उदाहरण में, लंबोदर अभिव्यक्ति में घोषित फ़ंक्शन को उच्च प्राथमिकता वाले धागे में स्थगित कहा जाता है।

 class Clazz { public: int m_varible; void Function(int _varible) { m_varible = _varible; }; }; std::shared_ptr<Clazz> clazz = std::make_shared<Clazz>(); clazz->m_varible = 101; std::function<void(std::shared_ptr<Clazz> )> function = [](std::shared_ptr<Clazz> clazz) { std::cout<<"call"<<clazz->m_varible<<std::endl; }; gcdpp::gcdpp_dispatch_async<std::shared_ptr<Clazz>>(gcdpp::gcdpp_dispatch_get_global_queue(gcdpp::GCDPP_DISPATCH_QUEUE_PRIORITY_HIGH), function, clazz); 

यह पैरामीटर के रूप में कस्टम कक्षाओं के साथ आस्थगित ऑपरेशन कॉल का उपयोग करने का एक उदाहरण है।

 void CParticleEmitter::_OnTemplateLoaded(std::shared_ptr<ITemplate> _template) { std::function<void(void)> function = [this](void) { std::shared_ptr<CVertexBuffer> vertexBuffer = std::make_shared<CVertexBuffer>(m_settings->m_numParticles * 4, GL_STREAM_DRAW); ... m_isLoaded = true; }; thread_concurrency_dispatch(get_thread_concurrency_main_queue(), function); } 

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

निष्कर्ष

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

सोर्स कोड ओपन एक्सेस सोर्स कोड में मिल सकते हैं। वीएस 2012 के तहत, परियोजना को अभी तक धक्का नहीं दिया गया है, लेकिन मुझे लगता है कि यह जल्द ही वहां दिखाई देगा।

पीएस की पर्याप्त आलोचना की प्रतीक्षा ...