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

यह सामग्री यैंडेक्स डेटा एनालिसिस स्कूल के शिक्षक इवान पुजेरेवस्की की एक रिपोर्ट के ट्रांसक्रिप्ट पर आधारित है।

वीडियो रिकॉर्डिंग

1. सामग्री

2. परिचय

सभी को नमस्कार, मेरा नाम इवान पुजेरेवस्की है, मैं यैंडेक्स के लिए काम करता हूं। पिछले छह वर्षों से मैं डेटा भंडारण और प्रसंस्करण के बुनियादी ढांचे में लगा हुआ हूं, अब मैंने यात्रा, होटल और टिकट की तलाश में उत्पाद पर स्विच कर दिया है। चूंकि मैंने बुनियादी ढांचे में लंबे समय तक काम किया, इसलिए मुझे अलग-अलग लोड किए गए एप्लिकेशन को लिखने का अनुभव प्राप्त हुआ है। हमारा इंफ्रास्ट्रक्चर हजारों मशीनों पर लगातार 24*7*365 प्रतिदिन बिना रुके चल रहा है। स्वाभाविक रूप से, आपको कोड लिखने की आवश्यकता है ताकि यह मज़बूती से और कुशलता से काम करे और कंपनी द्वारा किए गए कार्यों को हल कर सके।

आज हम एसिंक्रोनस के बारे में बात करेंगे। अतुल्यकालिक क्या है? यह समय के साथ किसी चीज का बेमेल होना है। इस विवरण से यह स्पष्ट नहीं है कि मैं आज के बारे में क्या बात करता हूं। किसी तरह इस मुद्दे को स्पष्ट करने के लिए, मुझे एक उदाहरण की आवश्यकता है "ला हैलो, दुनिया!"। अतुल्यकालिक आमतौर पर नेटवर्क एप्लिकेशन लिखने के संदर्भ में होता है, इसलिए मेरे पास "हैलो, वर्ल्ड" का नेटवर्क एनालॉग होगा। यह एक पिंग-पोंग ऐप है। कोड इस तरह दिखता है:

 socket s; string x; x = read_from_socket(s, 4); if (x == "ping") { write_to_socket(s, "pong"); } return; 

मैं एक सॉकेट बनाता हूं, वहां से एक पंक्ति पढ़ता हूं, और जांचें कि क्या यह पिंग है, तो मैं जवाब में पोंग लिखता हूं। बहुत ही सरल और स्पष्ट। जब आप अपने कंप्यूटर स्क्रीन पर ऐसा कोड देखते हैं तो क्या होता है? हम इस कोड को इन चरणों के अनुक्रम के रूप में समझते हैं:

वास्तविक भौतिक समय के दृष्टिकोण से, सब कुछ थोड़ा सा पक्षपाती है।

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

I / O के दौरान, पैकेट का नेटवर्क और सभी परिचर भारी, निम्न-स्तरीय कार्यों में आदान-प्रदान किया जाता है। आइए एक विचार प्रयोग करें: इस तरह के एक कार्यक्रम को लें, इसे एक भौतिक प्रोसेसर पर चलाएं और बहाना करें कि हमारे पास कोई ऑपरेटिंग सिस्टम नहीं है, तो क्या होगा? प्रोसेसर बंद नहीं कर सकता है, यह बिना किसी निर्देशों के पालन के उपाय करना जारी रखता है, बस व्यर्थ में ऊर्जा बर्बाद कर रहा है।

प्रश्न उठता है कि क्या हम इस अवधि के दौरान कुछ भी उपयोगी कर सकते हैं। यह एक बहुत ही स्वाभाविक प्रश्न है, जिसका उत्तर हमें प्रोसेसर शक्ति को बचाने और कुछ उपयोगी के लिए उपयोग करने की अनुमति देता है, जबकि हमारा आवेदन कुछ भी नहीं कर रहा है।

3. मूल अवधारणा

3.1। निष्पादन का धागा

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

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

3.2। मल्टीटास्किंग और कंसर्ट

उत्पादकता की आधारशिला इस तरह की चाल करने की क्षमता है: जब मेरे पास निष्पादन का एक धागा होता है जिसमें इसके भौतिक समय स्कैन में voids होते हैं, तो इन voids को कुछ उपयोगी के साथ भरें - निष्पादन के अन्य थ्रेड्स के चरणों का पालन करें।

डेटाबेस आमतौर पर एक ही समय में कई ग्राहकों की सेवा करते हैं। यदि हम उच्च स्तर के निष्पादन के एक धागे के ढांचे के भीतर निष्पादन के कई थ्रेड्स पर काम को जोड़ सकते हैं, तो इसे मल्टीटास्किंग कहा जाता है। यही है, मल्टीटास्किंग है जब मैं निष्पादन के एक बड़े प्रवाह के ढांचे के भीतर कार्य करता हूं जो छोटे कार्यों के समाधान के अधीनस्थ हैं।

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

यह महत्वपूर्ण है कि इन अवधारणाओं को भ्रमित न करें, क्योंकि वे विभिन्न श्रेणियों में आते हैं। मल्टीटास्किंग आपके प्रोग्राम की एक विशेषता है कि यह आंतरिक रूप से विभिन्न कार्यों पर एक चर काम के रूप में संरचित है। Concurrency रनटाइम वातावरण की एक संपत्ति है जो आपको एक घड़ी चक्र में कई कार्यों पर काम करने में सक्षम बनाती है।

कई मायनों में, एसिंक्रोनस कोड और एसिंक्रोनस कोड लिखना मल्टीटास्किंग कोड लिख रहा है। मुख्य कठिनाई यह है कि मैं कार्यों को कैसे लागू करूं और उन्हें कैसे प्रबंधित करूं। इसलिए, आज हम इस बारे में बात करेंगे - मल्टीटास्किंग कोड लिखना।

4. अवरुद्ध और प्रतीक्षा करना

आइए कुछ सरल उदाहरण से शुरू करते हैं। वापस पिंग-पोंग:

 socket s; string x; x = read_from_socket(s, 4); if (x == "ping") { write_to_socket(s, "pong"); } return; 

जैसा कि हमने पहले ही चर्चा की है, पढ़ने और सफेद लाइनों के बाद निष्पादन का धागा सो जाता है, यह अवरुद्ध है। आमतौर पर हम कहते हैं, "प्रवाह अवरुद्ध है।"

 socket s; string x; x = read_from_socket(s, 4); /* thread is blocked here */ if (x == "ping") { write_to_socket(s, "pong"); /* thread is blocked here */ } return; 

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

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

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

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

इसके अलावा, ऑपरेटिंग सिस्टम एक जटिल चीज है, और कर्नेल के लिए हमारे एप्लिकेशन से स्विचिंग संदर्भ में कुछ माइक्रोसेकंड खर्च होते हैं, जो कुछ सरल गणनाओं के साथ, हमें प्रति सेकंड लगभग 20-100 हजार संदर्भ स्विच का अनुमान देता है। इसका मतलब है कि अगर हम एक वेब सर्वर लिखते हैं, तो एक सेकंड में हम लगभग 20 हजार अनुरोधों को संसाधित कर सकते हैं, यह मानते हुए कि प्रसंस्करण अनुरोध सिस्टम की तुलना में दस गुना अधिक महंगा है।

4.1। गैर-अवरुद्ध प्रतीक्षा

यदि आप ऐसी स्थिति में आते हैं कि आपको नेटवर्क के साथ अधिक कुशलता से काम करने की आवश्यकता है, तो आप इंटरनेट पर मदद की तलाश शुरू करते हैं और चुनिंदा / एपोल का उपयोग करने के लिए आते हैं। इंटरनेट पर लिखा है कि यदि आप एक ही समय में हजारों कनेक्शनों की सेवा करना चाहते हैं, तो आपको एपोल की आवश्यकता है, क्योंकि यह एक अच्छा तंत्र है और इसी तरह। आप दस्तावेज़ खोलते हैं और कुछ इस तरह देखते हैं:

 int select(int nfds, fd_set* readfds, fd_set* writefds, fd_set* exceptfds, struct timeval* timeout); void FD_CLR(int fd, fd_set* set); int  FD_ISSET(int fd, fd_set* set); void FD_SET(int fd, fd_set* set); void FD_ZERO(fd_set* set); int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event); int epoll_wait(int epfd, struct epoll_event* events, int maxevents, int timeout); 

ऐसे कार्य जिनमें इंटरफ़ेस में बहुत सारे डिस्क्रिप्टर होते हैं, जिनके साथ आप काम करते हैं (चयन के मामले में), या बहुत सारी घटनाओं को पास करते हैं
आपके एप्लिकेशन की सीमाओं के पार, ऑपरेटिंग सिस्टम का कर्नेल जिसे आपको संसाधित करने की आवश्यकता है (एपोल के मामले में)।

यह जोड़ने योग्य भी है कि आप चयन नहीं कर सकते हैं / एपोल नहीं कर सकते हैं, लेकिन एक पुस्तकालय जैसे कि लिबवू, जिसमें एपीआई में कोई घटना नहीं होगी, लेकिन कई कॉलबैक होंगे। लाइब्रेरी इंटरफ़ेस कहेगा: "प्रिय मित्र, सॉकेट को पढ़ने के लिए एक कॉलबैक प्रदान करें, जिसे मैं डेटा दिखाई देने पर कॉल करूंगा।"

 int uv_timer_start(uv_timer_t* handle, uv_timer_cb cb, uint64_t timeout, uint64_t repeat); typedef void (*uv_timer_cb)(uv_timer_t* handle); int uv_read_start(uv_stream_t* stream, uv_alloc_cb alloc_cb, uv_read_cb read_cb); int uv_read_stop(uv_stream_t*); typedef void (*uv_read_cb)(uv_stream_t* stream, ssize_t nread, const uv_buf_t* buf); int uv_write(uv_write_t* req, uv_stream_t* handle, const uv_buf_t bufs[], unsigned int nbufs, uv_write_cb cb); typedef void (*uv_write_cb)(uv_write_t* req, int status); 

पिछले अध्याय में हमारे तुल्यकालिक कोड की तुलना में क्या बदलाव आया है? कोड अतुल्यकालिक हो गया है। इसका मतलब यह है कि हमने घटनाओं को मॉनिटर करने के समय में बिंदु निर्धारित करने के लिए तर्क को आवेदन में लिया। स्पष्ट चयन / एपोल कॉल ऐसे बिंदु हैं जहां हम उन घटनाओं के बारे में जानकारी के लिए ऑपरेटिंग सिस्टम से पूछते हैं। हमने अपने एप्लिकेशन कोड में यह भी चुना कि किस कार्य को अगले पर काम करना है।

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

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

हम C ++ डेवलपर्स को क्यों लिखते हैं जो विशिष्ट एप्लिकेशन समस्याओं को लिखते हैं और हल करते हैं, वे शायद हमारे कोड में एक इवेंट मॉडल को खींचना चाहते हैं? यदि हम अपने कोड में कई कार्यों पर काम को खींचते और छोड़ते हैं और उन्हें प्रबंधित करते हैं, तो कर्नेल और इसके विपरीत संक्रमण की कमी के कारण, हम थोड़ी तेजी से काम कर सकते हैं और समय की प्रति यूनिट अधिक उपयोगी क्रियाएं कर सकते हैं।

हमारे द्वारा लिखे गए कोड के संदर्भ में यह क्या दर्शाता है? उदाहरण के लिए, एक उच्च-प्रदर्शन HTTP सर्वर, nginx को लें। यदि आप इसका कोड पढ़ते हैं, तो यह एक अतुल्यकालिक मॉडल पर बनाया गया है। कोड को पढ़ना बहुत कठिन है। जब आप अपने आप से पूछते हैं कि एक ही HTTP अनुरोध को संसाधित करते समय वास्तव में क्या होता है, तो यह पता चलता है कि कोड में बहुत सारे टुकड़े हैं, अलग-अलग फाइलों में, कोड आधार के विभिन्न कोणों पर। प्रत्येक टुकड़ा संपूर्ण HTTP अनुरोध की सेवा के हिस्से के रूप में एक छोटा सा काम करता है। उदाहरण के लिए:

 static void ngx_http_request_handler(ngx_event_t *ev) { … if (c->close) { ngx_http_terminate_request(r, 0); return; } if (ev->write) { r->write_event_handler(r); } else { r->read_event_handler(r); } ... } /* where the handler... */ typedef void (*ngx_http_event_handler_pt)(ngx_http_request_t *r); struct ngx_http_request_s { /*... */ ngx_http_event_handler_pt read_event_handler; /* ... */ }; /* ...is set when switching to the next processing stage */ r->read_event_handler = ngx_http_request_empty_handler; r->read_event_handler = ngx_http_block_reading; r->read_event_handler = ngx_http_test_reading; r->read_event_handler = ngx_http_discarded_request_body_handler; r->read_event_handler = ngx_http_read_client_request_body_handler; r->read_event_handler = ngx_http_upstream_rd_check_broken_connection; r->read_event_handler = ngx_http_upstream_read_request_handler; 

एक अनुरोध संरचना है, जिसे इवेंट हैंडलर के लिए भेजा जाता है जब सॉकेट सिग्नल पढ़ता है या पहुंच लिखता है। इसके अलावा, यह हैंडलर लगातार अनुरोध प्रसंस्करण की स्थिति के आधार पर कार्यक्रम के पाठ्यक्रम में स्विच करता है। या तो हम हेडर पढ़ते हैं, या हम अनुरोध के शरीर को पढ़ते हैं, या हम डेटा के लिए ऊपर की ओर पूछते हैं - सामान्य तौर पर, कई अलग-अलग राज्य हैं।

इस तरह के कोड को पढ़ना मुश्किल है क्योंकि यह, संक्षेप में, घटनाओं की प्रतिक्रिया के संदर्भ में वर्णित है। हम ऐसी स्थिति में हैं और आने वाली घटनाओं पर एक निश्चित तरीके से प्रतिक्रिया करते हैं। HTTP अनुरोध को संसाधित करने की संपूर्ण प्रक्रिया की समग्र तस्वीर का अभाव है।

एक अन्य विकल्प, जिसे अक्सर जावास्क्रिप्ट में उपयोग किया जाता है, कॉलबैक-आधारित कोड का निर्माण करना है जब हम इंटरफ़ेस कॉल पर अपने कॉलबैक को आगे बढ़ाते हैं, जिसमें एक घटना के लिए आमतौर पर कुछ अन्य नेस्टेड कॉलबैक होते हैं, और इसी तरह।

 int LibuvStreamWrap::ReadStart() { return uv_read_start(stream(), [](uv_handle_t* handle, size_t suggested_size, uv_buf_t* buf) { static_cast<LibuvStreamWrap*>(handle->data)->OnUvAlloc(suggested_size, buf); }, [](uv_stream_t* stream, ssize_t nread, const uv_buf_t* buf) { static_cast<LibuvStreamWrap*>(stream->data)->OnUvRead(nread, buf); }); } /* ...for example, parsing http... */ for (p=data; p != data + len; p++) { ch = *p; reexecute: switch (CURRENT_STATE()) { case s_start_req_or_res: /*... */ case s_res_or_resp_H: /*... */ case s_res_HT: /*... */ case s_res_HTT: /* ... */ case s_res_HTTP: /* ... */ case s_res_http_major: /*... */ case s_res_http_dot: /*... */ /* ... */ 

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

इस प्रकार, हमारे कोड में मल्टीटास्किंग (कार्य कार्यों को चुनने और उन्हें बहुसंकेतन करने का तर्क) का परिचय देते हुए, हमें प्रभावी प्राथमिकता मिलती है और कार्य प्राथमिकता पर नियंत्रण होता है, लेकिन हम पठनीयता में उनमें से बहुत कुछ खो देते हैं। इस कोड को पढ़ना मुश्किल है और इसे बनाए रखना मुश्किल है।

क्यों? मान लीजिए मेरे पास एक साधारण मामला है, उदाहरण के लिए, मैंने एक फ़ाइल पढ़ी और इसे नेटवर्क पर स्थानांतरित कर दिया। एक गैर-अवरुद्ध संस्करण में, यह मामला इस तरह के एक रैखिक राज्य मशीन के अनुरूप होगा:

• प्रारंभिक अवस्था
• फ़ाइल पढ़ना प्रारंभ करें,
• फ़ाइल सिस्टम से प्रतिक्रिया की प्रतीक्षा कर रहा है,
• सॉकेट में फ़ाइल लिखना,
• अंतिम स्थिति।

अब, मान लीजिए कि मैं इस फाइल में डेटाबेस से जानकारी जोड़ना चाहता हूं। एक सरल विकल्प:

• प्रारंभिक अवस्था
• एक फ़ाइल पढ़ना
• फ़ाइल पढ़ें
• डेटाबेस से पढ़ना
• डेटाबेस से पढ़ें,
• मैं एक सॉकेट के साथ काम करता हूं
• सॉकेट के लिए लिखा है।

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

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

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

5. वायदा / वादा

समस्या को हल करने के लिए, आपको स्थिति को आसान बनाने की आवश्यकता है।

एक कार्यक्रम है, इसमें काले और लाल घेरे हैं। निष्पादन का हमारा प्रवाह काले घेरे हैं; कभी-कभी वे लाल रंग के साथ वैकल्पिक होते हैं जब धारा अपना काम जारी नहीं रख सकती। समस्या यह है कि निष्पादन के हमारे काले धागे के लिए आपको अगले काले घेरे में जाने की आवश्यकता है, जो कब पता नहीं चलेगा।

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

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

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

स्तर 1 में, हमने इस पेंडोरा के बॉक्स को खोला, और यह कोड में बहुत सारे स्विच, केस, शर्तों, शाखाओं, राज्यों को लाया। मैं कुछ समझौता करना चाहूंगा ताकि कोड अपेक्षाकृत पठनीय हो, लेकिन स्तर 1 के सभी फायदे बरकरार रहे।

सौभाग्य से हमारे लिए, 1988 में वितरित प्रणालियों में शामिल लोग, बारबरा लिस्कॉव और लुबा शिरिर, ने समस्या का एहसास किया, और भाषाई परिवर्तनों की आवश्यकता के लिए आए। प्रोग्रामिंग भाषा में निर्माणों को जोड़ना आवश्यक है जो घटनाओं के बीच अस्थायी संबंधों को व्यक्त करने की अनुमति देता है - वर्तमान समय में और भविष्य में अनिश्चित क्षण में।

इन्हें प्रॉमिस कहा जाता है। अवधारणा शांत है, लेकिन यह बीस साल से एक शेल्फ पर धूल इकट्ठा कर रहा है। — , Twitter, Ruby on Rails Scala, , , , future . Your Server as a Function. , .

Scala, , ++ ?

, Future. T c : , - .

 template <class T> class Future <T> 

, , , . , «», , . Future «», Promise — «». ; , JavaScript, Promise — , Java – Future.

, . , , boost::future ( std::future) — , .

5.1। Future & Promise

 template <class T> class Future { bool IsSet() const; const T& Get() const; T* TryGet() const; void Subscribe(std::function<void(const T&)> cb); template <class R> Future<R> Then( std::function<R(const T&)> f); template <class R> Future<R> Then( std::function<Future<R>(const T&)> f); }; template <class T> Future<T> MakeFuture(const T& value); 

, , - , . , , , . , , — , , . Then, .

 template <class T> class Promise { bool IsSet() const; void Set(const T& value); bool TrySet(const T& value); Future<T> ToFuture() const; }; template <class T> Promise<T> NewPromise(); 

. , . «, , , ».

5.2।

? , . Then — , .

, — future --, - t — . , , , f, - r.

t f. , , r.

: t, , r . :

 template <class T> template <class R> Future<R> Future<T>::Then(std::function<R(const T&)> f) { auto promise = NewPromise<R>(); this->Subscribe([promise] (const T& t) { auto r = f(t); promise.Set(r); }); return promise.ToFuture(); } 

:

• Promise R ,
• Future<T> t ,
• , r = f(t) ,
• r Promise ,
• Promise .

f , R , Future<R> , R . :

• T ,
• , T , , R ,
• , R , , .

 template <class T> template <class R> Future<R> Future<T>::Then(std::function<Future<R>(const T&)> f) { auto promise = NewPromise<R>(); this->Subscribe([promise] (const T& t) { auto that = f(t); that.Subscribe([promise] (R r) { promise.Set(r); }); }); return promise.ToFuture(); } 

, - t. f, r, . , , .

, Then :

• Promise ,
• Subscribe -,
• Promise , Future .

, . , , , .

, , , -. , , -, Subscribe. , , , - . , .

5.3। उदाहरण

AsyncComputeValue, GPU, . Then, , (2v+1) ² .

 Future<int> value = AsyncComputeValue(); //    value.Subscribe([] (int v) { std::cerr << "Value is: " << v << std::endl; }); 

. , : (2v+1) ² . , .

 //  (2v+1)^2 Future<int> anotherValue = value .Then([] (int v) { return 2 * v; }) .Then([] (int u) { return u + 1; }) .Then([] (int w) { return w * w; }); 

, , . .

. : , ; ; .

 Future<int> GetDbKey(); Future<string> LoadDbValue(int key); Future<void> SendToMars(string message); Future<void> ExploreOuterSpace() { return GetDbKey() // Future<int> .Then(&LoadDbValue) // Future<string> .Then(&SendToMars); // Future<void> } ExploreOuterSpace().Subscribe( [] () { std::cout << "Mission Complete!" << std::endl; }); 

— ExploreOuterSpace. Then; — — , . ( ) . .

5.4। Any-

: Future , , . , , :

 template <class T> Future<T> Any(Future<T> f1, Future<T> f2) { auto promise = NewPromise<T>(); f1.Subscribe([promise] (const T& t) { promise.TrySet(t); }); f2.Subscribe([promise] (const T& t) { promise.TrySet(t); }); return promise.ToFuture(); } //     

, Any-, Future : , . , , .

, , , , , . « DB1, DB2, — - ».

5.5। All-

. , , , ( T1 T2), T1 T2 , , .

 template <class T1, class T2> Future<std::tuple<T1, T2>> All(Future<T1> f1, Future<T2> f2) { auto promise = NewPromise<std::tuple<T1, T2>>(); auto result = std::make_shared< std::tuple<T1, T2> >(); auto counter = std::make_shared< std::atomic<int> >(2); f1.Subscribe([promise, result, counter] (const T1& t1) { std::get<0>(*result) = t1; if (--(*counter) == 0) { promise.Set(*result)); } }); f2.Subscribe([promise, result, counter] (const T2& t2) { /*  */ } return promise.ToFuture(); } //     

nginx. , , . nginx « », « », « » . All- , . .

5.6.

Future Promises — legacy-, . callback- , , : Future, , callback- Future.

 //   cb     void LegacyAsyncComputeStuff(std::function<void(int)> cb); //      Future Future<int> ModernAsyncComputeStuff() { auto promise = NewPromise<int>(); LegacyAsyncComputeStuff( [promise] (int value) { promise.Set(value); }); return promise.ToFuture(); } 

: , Future .

6.

, , . .

 Future<Request> GetRequest(); Future<Payload> QueryBackend(Request req); Future<Response> HandlePayload(Payload pld); Future<void> Reply(Request req, Response rsp); // req  2 :  QueryBackend   Reply GetRequest().Subscribe( [] (Request req) { auto rsp = QueryBackend(req) .Then(&HandlePayload) .Then(Bind(&Reply, req)); }); 

. Request, - . , . , , , . , - .

, , . ? — , request payload, — , .

, Java Netty. , , . , , .

, GetRequest, QueryBackend, HandlePayload Reply , Future.

, , Future T — WaitFor.

 Future<Request> GetRequest(); Future<Payload> QueryBackend(Request req); Future<Response> HandlePayload(Payload pld); Future<void> Reply(Request req, Response rsp); template <class T> T WaitFor(Future<T> future); // req  2 :  QueryBackend   Reply GetRequest().Subscribe( [] (Request req) { auto rsp = QueryBackend(req) .Then(&HandlePayload) .Then(Bind(&Reply, req)); }); 

:

 Future<Request> GetRequest(); Future<Payload> QueryBackend(Request req); Future<Response> HandlePayload(Payload pld); Future<void> Reply(Request req, Response rsp); template <class T> T WaitFor(Future<T> future); auto req = WaitFor(GetRequest()); auto pld = WaitFor(QueryBackend(req)); auto rsp = WaitFor(HandlePayload(pld)); WaitFor(Reply(req, rsp)); 

: Future, . . , . .

. . - 0, , , mutex+cvar future. . , .

6.1।

, . , , , , - , . , - .

— «» , , . . . : boost::asio boost::fiber.

, . यह कैसे करना है?

6.2। WaitFor

, , boost::context, : , ; , . x86/64 , , .

 //      class MachineContext; //     from,    to void SwitchContext(MachineContext* from, MachineContext* to); //      – boost::context //    // * x86_64-ASM (push...-movq(rsp,eip)-pop...-jmpq) // * makecontext/swapcontext // * setjmp/longjmp 

, goto: , , , .

, - . Fiber — . +Future. , , Future, .

 class Fiber { /*    */ MachineContext context_; Future<void> future_; }; 

 class Scheduler { /*    */ void WaitFor(Future<void> future); void Loop(); MachineContext loop_context_; Fiber* current_fiber_; std::deque<Fiber*> run_queue_; }; 

Future , , , . : Loop, , , , , .

WaitFor?

 thread_local Scheduler* ThisScheduler; template <class T> T WaitFor(Future<T> future) { ThisScheduler->WaitFor(future.As<void>()); return future.Get(); } void Scheduler::WaitFor(Future<void> future) { current_fiber_->future_ = future; SwitchContext(¤t_fiber_->context_, &loop_context_); } 

: , - , , Future void, . .

Future<void> , , - .

WaitFor : : « Fiber Future», ( ) .

, :
ThisScheduler->WaitFor return future.Get() , .

? , Future, .

6.3।

- , , , - , . SwitchContext , 2 — .

 void Scheduler::Loop() { while (true) { // (1)     (= !) current_fiber_ = run_queue_.front(); run_queue_.pop_front(); SwitchContext(&loop_context_, ¤t_fiber_->context_); // (2) ,      //… 

? , , , Future, Future, , , .

 void Scheduler::Loop() { while (true) { // (1)     … // (2) ,      if (current_fiber_->future_) { current_fiber_->future_.Subscribe( [this, fiber = current_fiber_] { fiber->future_ = nullptr; run_queue_.push_back(fiber); }); } //… 

, . :

WaitFor — .

Switch- .

Future ( ), , . - Fiber.

WaitFor Future , - , Future . :

 Future<Request> GetRequest(); Future<Payload> QueryBackend(Request req); Future<Response> HandlePayload(Payload pld); Future<void> Reply(Request req, Response rsp); template <class T> T WaitFor(Future<T> future); auto req = WaitFor( GetRequest()); auto pld = WaitFor( QueryBackend(req)); auto rsp = WaitFor( HandlePayload(pld)); WaitFor( Reply(req, rsp)); 

, , , . , , .

6.4। Coroutine TS

? — . Coroutine TS, , WaitFor CoroutineWait, CoroutineTS — - . , - . , Waiter Co, , .

7. ?

. , , , . , , , .

— . , . . , . , , , , .

- , , . , . , , .

, ? , .

. , , , , . . , , , , .

nginx, , , , , . , , , future promises.

, , , , , , , .

futures, promises actors. . , .

: , , , . , , , , . ? , .

विज्ञापन का मिनट। 19-20 C++ Russia 2019. , , Grimm Rainer «Concurrency and parallelism in C++17 and C++20/23» , C++ . , . , , - .