C # से C ++ तक प्रतीक्षा / async एनालॉग लिखने के लिए एक तकनीक

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

प्रागितिहास

इस लेख के सभी कोड उदाहरण मेरे द्वारा "क्लासिक" विवादों में से एक के रूप में "सी #" के रूप में खोजे गए थे। C ++ ”एक मंच पर। तर्क समाप्त हो गया, लेकिन कोड बना रहा, और मैंने सोचा कि क्यों न इसे एक सामान्य लेख में बनाया जाए, जो कि हैबे पर इनपुट के रूप में काम करेगा। ऐसे ऐतिहासिक कारणों के कारण, लेख में C # और C ++ दृष्टिकोणों की कई तुलनाएं होंगी।

समस्या कथन - एसिंक्रोनस प्रोग्रामिंग

काफी बार, एक कार्य एक अलग स्ट्रीम में कुछ क्रियाएं करने के लिए कार्य में उत्पन्न होता है और फिर परिणाम को मूल (आमतौर पर UI) स्ट्रीम में संसाधित करता है। यह तथाकथित अतुल्यकालिक प्रोग्रामिंग की किस्मों में से एक है। यह कार्य सर्वविदित है और अधिकांश प्रोग्रामिंग भाषाओं में इसके कई समाधान हैं। उदाहरण के लिए, C ++ में, यह इस तरह दिख सकता है:

auto r=async(launch::async, [&]{return CalcSomething(params);}); DoAnother(); ProcessResult(r.get());//get -  

कॉल ब्लॉकिंग योजना के लिए। या तो:

 auto r=async(launch::async, [&]{return CalcSomething(params);}); while(r.wait_for(chrono::seconds(0))!=future_status::ready) DoAnother(); ProcessResult(r.get()); 

पूछताछ चार्ट के साथ। ठीक है, यूआई धाराओं के लिए, सामान्य तौर पर, सबसे आसान तरीका पहले से काम कर रहे चक्र का उपयोग करना और अधिसूचना योजना बनाना है:

 thread([=]{PostMessage(CalcSomething(params));}).detach(); ... OnDataMessage(Data d){ProcessResult(d.get<type>());} 

जाहिर तौर पर यहां कुछ भी जटिल नहीं है। यह C ++ कोड है, लेकिन मान लीजिए C # में सब कुछ सचमुच एक ही लिखा जाएगा, केवल थ्रेड और टास्क धागे और भविष्य के बजाय होंगे। लेकिन अंतिम विकल्प में एक छोटा माइनस है: गणना कोड और प्रोसेसिंग कोड अलग-अलग संदर्भों में हैं (और यहां तक ​​कि अलग-अलग फाइलों में भी हो सकते हैं)। कभी-कभी यह अधिक कठोर वास्तुकला के लिए भी उपयोगी होता है, लेकिन आप हमेशा कम स्क्रिबल चाहते हैं ... सी # के हाल के संस्करणों में, एक जिज्ञासु समाधान दिखाई दिया है।

सी # कार्यान्वयन

C # के हाल के संस्करणों में, हम बस लिख सकते हैं:

 private async void Handler(Params prms) { var r = await Task.Run(() => CalcSomething(prms)); ProcessResult(r); } 

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

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

Soprotsedury

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

सी # में, ऐसे शास्त्रीय प्रयोजनों के लिए, लेकिन जिज्ञासु सिंथैटिक चीनी के कार्यान्वयन के लिए काप्रोडेक्टर्स का उपयोग नहीं किया गया था। यहाँ कार्यान्वयन भाषा में बनाया गया है, लेकिन सबसे अच्छे से दूर है। यह तथाकथित स्टैकलेस कार्यान्वयन है, जो अनिवार्य रूप से एक राज्य मशीन है जो आवश्यक स्थानीय चर और प्रवेश बिंदुओं को संग्रहीत करता है। यह इस बात से है कि C # कार्यान्वयन के अधिकांश कमियां अनुसरण करती हैं। और पूरे कॉल स्टैक और मशीन के अतिरिक्त ओवरहेड पर "async" रखने की आवश्यकता है। वैसे, इंतजार C # में सह-प्रक्रियाओं की पहली उपस्थिति नहीं है। उपज समान है, केवल अधिक सीमित है।

C ++ में हमारे पास क्या है? भाषा में स्वयं कोई सह-प्रक्रिया नहीं है, लेकिन कई अलग-अलग पुस्तकालय कार्यान्वयन हैं। यह बूस्ट में भी है, और यह सबसे प्रभावी विकल्प - स्टैकफुल को लागू करता है। यह क्रमशः सभी प्रोसेसर और स्टैक रजिस्टरों को सहेजने / बहाल करने से काम करता है - अनिवार्य रूप से असली धागे की तरह, केवल यह सब ओएस का सहारा लिए बिना है, इसलिए यह लगभग तुरंत है। और बूस्ट में सब कुछ की तरह, यह अलग ओएस, कंपाइलर्स, प्रोसेसर पर ठीक काम करता है।

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

C ++ कार्यान्वयन

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

 using Coro=boost::coroutines::coroutine<void()>; Coro c([](Coro::caller_type& yield){ ... yield();//  ... yield();//  ... }); ... c();//       

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

अब हमारे पास वह सब कुछ है जो हमें चाहिए। यह टेम्प्लेट और मैक्रोज़ का एक छोटा सा जादू लागू करने के लिए बना हुआ है (यह सिर्फ सी # विकल्प की तरह दिखने के लिए है) और हमें मिलता है:

 using __Coro=boost::coroutines::coroutine<void()>; void Post2UI(const void* coro); template<typename L> auto __await_async(const __Coro* coro, __Coro::caller_type& yield, L lambda)->decltype(lambda()) { auto f=async(launch::async, [=](){ auto r=lambda(); Post2UI(coro); return r; }); yield(); return f.get(); } void CallFromUI(void* c) { __Coro* coro=static_cast<__Coro*>(c); (*coro)(); if(!*coro) delete coro; } #define async_code(block) { __Coro* __coro=new __Coro; *__coro=__Coro([=](__Coro::caller_type& __yield){block});} #define await_async(l) __await_async(__coro, __yield, l) 

पूरे कार्यान्वयन में सरल कोड की कुछ दयनीय 20 लाइनें हैं! बेशक, आप उन्हें एक अलग एचपीपी फ़ाइल में डाल सकते हैं और इसे पुस्तकालय की तरह कुछ कह सकते हैं, लेकिन यह सिर्फ हास्यास्पद होगा। सच है, हमें कुछ और पंक्तियों को परिभाषित करने की आवश्यकता है, जो पहले से ही हमारे जीयूआई ढांचे (या यहां तक ​​कि सामान्य रूप से देशी एपीआई) की पसंद पर निर्भर करते हैं। कुछ इस तरह:

 void Post2UI(const void* coro) {PostMessage(coro);} void OnAsync(Event& event) {CallFromUI(event.Get<void*>());} 

लेकिन यह केवल कुछ पंक्तियाँ हैं, संपूर्ण अनुप्रयोग के लिए एक और सभी अनुप्रयोगों के लिए समान ढाँचे पर। उसके बाद, हम इस कोड को आसानी से लिख सकते हैं:

 void Handler(Params params) async_code ( auto r = await_async([&]{return CalcSomething(params);}); ProcessResult(r); ) 

और गणना का क्रम ठीक उसी प्रकार होगा जैसा कि C # संस्करण में है। और हमें C # की तरह फंक्शन सिग्नेचर (कॉल कॉल के दौरान async जोड़ें) को बदलना नहीं था। इसके अलावा, यहाँ हम कार्यों पर एक अतुल्यकालिक कार्य चलाने तक सीमित नहीं हैं। हम एक ही समय में समानांतर निष्पादन के लिए कई अतुल्यकालिक ब्लॉक चला सकते हैं, या एक लूप में भी चल सकते हैं। उदाहरण के लिए, यह कोड:

 void Handler(const list<string>& urls) { for(auto url: urls) async_code ( result+=await_async([&]{return CheckServer(url);}); ) } 

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

परीक्षण

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

 class MyWindow: public Window { void TestAsync(int n) async_code ( output<<L"    "<<this_thread::get_id()<<'\n'; auto r=await_async([&]{ this_thread::sleep_for(chrono::seconds(1)); wostringstream res; res<<L"    "<<this_thread::get_id()<<L"   "<<n; return res.str(); }); output<<L"    "<<this_thread::get_id()<<L": "<<r<<'\n'; ) void OnButtonClick(Event&) { TestAsync(12345); TestAsync(67890); output<<L" MessageBox   "<<this_thread::get_id()<<'\n'; MessageBox(L"!"); output<<L"MessageBox    "<<this_thread::get_id()<<'\n'; } Editbox output; }; class MyApp : public App { virtual bool OnInit() { SetTopWindow(new MyWindow); return true; } void OnAsync(Event& event) { CallFromUI(event.Get<void*>()); } }; void Post2UI(const void* coro) { GetApp().PostMessage(ID_ASYNC, coro); } 

MessageBox मोडल विंडो के साथ काम करने की जाँच के लिए खड़ा है। प्राप्त परिणाम:

धागा 1 से एसिंक्रोनस चलाएँ
धागा 1 से एसिंक्रोनस चलाएँ
संदेश बॉक्स को स्ट्रीम 1 से दिखाएं
हम धारा 1 में परिणाम दिखाते हैं: धारा 2 में डेटा 12345 पर काम पूरा हो गया है
हम स्ट्रीम 1 में परिणाम दिखाते हैं: डेटा 67890 पर धारा 3 में काम पूरा हो गया है
संदेश बॉक्स थ्रेड 1 में बंद है

परिणाम

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

साहित्य

1. en.cppreference.com/w/cpp/thread - मानक लाइब्रेरी में समर्थन को मल्टीथ्रेड करना।
2. www.boost.org/doc/libs/1_54_0/libs/coroutine/doc/html/index.html - बूस्ट में सह -प्रक्रियाओं का कार्यान्वयन।

जोड़ 1

यह टिप्पणी ठीक से नोट की गई है कि C # से प्रतीक्षारत / async न केवल विभिन्न थ्रेड्स के साथ, बल्कि एक के ढांचे के भीतर भी काम कर सकता है। खैर, वास्तव में यह स्पष्ट रूप से जिस तरह से होना चाहिए, क्योंकि है यह सिर्फ सह-प्रक्रियाओं का सबसे अच्छा कार्यान्वयन नहीं है, लेकिन वे मूल रूप से सिर्फ ऐसे काम के लिए बनाए गए थे। और यह स्वाभाविक है कि बूस्ट की प्रक्रियाओं की मदद से यह काफी तुच्छ तरीके से लागू किया जाता है। मैंने ऐसा कोई कोड केवल इसलिए नहीं दिखाया क्योंकि यह समस्या के मेरे मूल कथन (लेख की शुरुआत देखें) का हिस्सा नहीं था, और मुझे ऐसे कोड में बिल्कुल भी समझदारी नहीं है। लेकिन चूंकि वे भी सामान्यता के लिए टिप्पणियों में रुचि रखते थे (यह दिखाने के लिए कि इस तरह का समाधान पूरी तरह से प्रतीक्षित / async की जगह लेता है), मैं अभी भी इसे यहां दिखाऊंगा।

और इसलिए, हमारे कार्यान्वयन में जोड़ें (जो 20 लाइनों का है) कुछ और:

 template<typename L> auto __await(const __Coro* coro, __Coro::caller_type& yield, L lambda)->decltype(lambda()) { Post2UI(coro); yield(); return lambda(); } #define await(l) __await_async(__coro, __yield, l) 

और उसके बाद हम इस तरह से लिख पाएंगे (कोड पहले जैसा ही है, बस बदला हुआ इंतजार है।

 void Handler(Params params) async_code ( auto r = await([&]{return CalcSomething(params);}); ProcessResult(r); ) 

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