OmniThreadLibrary लाइब्रेरी - एक डेल्फी पर्यावरण में सरल मल्टीथ्रेडिंग

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


शीर्षक में शामिल विषय बहुत व्यापक है। नीचे जो कुछ लिखा जाएगा वह हिमखंड का सिरा भी नहीं है, बल्कि समुद्र के ऊपर 10,000 मीटर की ऊंचाई पर एक उड़ान है जिसमें ये हिमखंड तैरते हैं। ऐसा लेख क्यों लिखें? बल्कि, लंबे समय से उपलब्ध व्यापक अवसरों पर ध्यान देने के लिए, लेकिन जो किसी कारण से बहुत से भयभीत और शर्मीले हैं।

डेल्फी क्यों?

मैं डेल्फी में बहुत लंबे समय से प्रोग्रामिंग कर रहा हूं और इसका आनंद लेना बंद नहीं करता। यह कई मायनों में एक अद्भुत भाषा है। इसकी विशिष्टता इस तथ्य में निहित है कि एक ही समय में यह आपको एक उच्च स्तर का कोड बनाने की अनुमति देता है, जबकि शेष "हार्डवेयर के करीब", क्योंकि आउटपुट एक मूल एप्लिकेशन है, जो जावा या .Net वर्चुअल मशीन के लिए कोड नहीं है। और इसी समय, डेल्फी भाषा बहुत सरल और संक्षिप्त है, इस पर कोड पढ़ने और समझने में आसान है, जिसे मैं C या C ++ में कोड के बारे में नहीं कह सकता (सी में डेवलपर्स के लिए मेरे सभी बड़े सम्मान के साथ, हालांकि कोई कहेगा कि) यह सिर्फ आदत की बात है)।
फिलहाल, डेल्फी ने अपनी पूर्व लोकप्रियता खो दी है। यह संभवतः इस तथ्य के कारण हुआ कि 2000 के दशक में इस उत्पाद को डेवलपर्स द्वारा कई वर्षों के लिए व्यावहारिक रूप से छोड़ दिया गया था, जिसके परिणामस्वरूप यह कुछ समय के लिए विकास के वातावरण की प्रतिस्पर्धी दौड़ से बाहर हो गया। दरअसल, 2002 में बोरलैंड द्वारा जारी डेल्फी 7 के बाद, अधिक या कम स्थिर उत्पाद केवल 2007 में दिखाई दिया। यह कोडगियर डेल्फी 2007 था, जो बोरलैंड की सहायक कंपनी कोडगियर द्वारा जारी किया गया था। डेल्फी 7 और डेल्फी 2007 के बीच सभी संस्करण व्यावहारिक रूप से अनुपयोगी थे। 2008 में, Borland ने Embarcadero Technologies को कोडगियर डिवीजन को बेच दिया, जिसके लिए (उसके लिए विशेष धन्यवाद!) तुरंत एक आधुनिक, उच्च-गुणवत्ता के विकास के वातावरण में जो कुछ भी मिला उसे चालू करना शुरू कर दिया। लेखन के समय डेल्फी का वर्तमान संस्करण Embarcadero Delphi XE2 है, जिसे सितंबर 2011 में रिलीज़ किया गया था। नवीनतम डेल्फी संस्करणों की उच्च गुणवत्ता के कारण, यह विकास पर्यावरण धीरे-धीरे खोए हुए पदों को जीत रहा है।

हमें मल्टीथ्रेडिंग की आवश्यकता क्यों है?

लोग एक ही समय में कंप्यूटर पर कई कार्य करना चाहते थे। इसे मल्टीटास्किंग कहा जाता है। ऑपरेटिंग सिस्टम के माध्यम से मल्टीटास्किंग लागू किया जाता है। लेकिन अगर ओएस एक ही समय में कई एप्लिकेशन निष्पादित करने में सक्षम है, तो एक ही बार में कई कार्यों को करने के लिए खुद के अंदर एक भी एप्लिकेशन क्यों नहीं। उदाहरण के लिए, फ़ाइलों की एक बड़ी सूची संग्रह करते समय, संग्रहकर्ता अगली फ़ाइल को एक साथ पढ़ सकता है, इस समय मेमोरी में, वर्तमान पढ़ने को संग्रहित करता है और डिस्क पर आउटपुट फ़ाइल के लिए परिणाम लिखता है। यानी "रीड" -> "आर्काइव" -> "रिजल्ट टू डिस्क" लिखने के बजाय एक फाइल में प्रत्येक फाइल पर क्रमिक रूप से, आप 3 स्ट्रीम शुरू कर सकते हैं, जिनमें से एक फाइल को मेमोरी में पढ़ेगा, दूसरी स्ट्रीम आर्काइव की जाएगी, और तीसरा डिस्क को बचाने के लिए है। एक और उदाहरण कुछ कम प्राथमिकता वाले कार्य की पृष्ठभूमि में प्रदर्शन है - उदाहरण के लिए, पृष्ठभूमि एक पाठ संपादक में खोली गई फ़ाइल की बैकअप प्रतिलिपि को सहेजती है।
यदि प्रोसेसर ने अपनी घड़ी की गति को उसी गति से बढ़ाना जारी रखा जैसा कि उन्होंने 90 और 2000 के दशक की शुरुआत में किया था, तो किसी को मल्टीथ्रेडिंग से परेशान नहीं होना पड़ेगा और क्लासिक सिंगल-थ्रेडेड कोड लिखना जारी रखना होगा। हालांकि, हाल के वर्षों में, प्रोसेसर एक कोर की गति को सक्रिय रूप से बढ़ाने के लिए बंद हो गए हैं, लेकिन उन्होंने खुद इन कोर की संख्या में वृद्धि करना शुरू कर दिया है। आधुनिक प्रोसेसर की क्षमता का 100% तक उपयोग करने के लिए, मल्टीथ्रेडिंग बस अपरिहार्य है।

मल्टीथ्रेडेड कोड लिखना मुश्किल क्यों है?

1) गलती करना आसान है।
जब कई अनुप्रयोग एक साथ कंप्यूटर पर चल रहे होते हैं, तो प्रत्येक प्रक्रिया का पता स्थान (मेमोरी) ऑपरेटिंग सिस्टम द्वारा अन्य प्रक्रियाओं से मज़बूती से अलग हो जाता है और किसी और के पते स्थान पर प्राप्त करना काफी मुश्किल होता है। एक ही प्रक्रिया के अंदर थ्रेड्स के साथ, इसके विपरीत, वे सभी प्रक्रिया के सामान्य पता स्थान के साथ काम करते हैं और इसे मनमाने ढंग से बदल सकते हैं। इसलिए, एक बहु-थ्रेडेड एप्लिकेशन में, आपको स्वतंत्र रूप से मेमोरी प्रोटेक्शन और थ्रेड सिंक्रोनाइज़ेशन को लागू करना होगा, जो अपेक्षाकृत जटिल लिखने की आवश्यकता की ओर जाता है, लेकिन साथ ही साथ पेलोड कोड नहीं ले जाता है। इस कोड को "बॉयलरप्लेट" (फ्राइंग पैन) कहा जाता है, क्योंकि इससे पहले कि आप कुछ भूनना शुरू करें, पैन को पहले पकाया जाना चाहिए। यह एक "गैर-मानक" बॉयलरप्लेट कोड लिखने की आवश्यकता है जो बहु-थ्रेडेड कंप्यूटिंग के विकास को वापस रखता है। थ्रेड्स को सिंक्रनाइज़ करने के लिए कई विशेष तंत्र हैं: इंटरलॉक किए गए प्रोसेसर निर्देश, ऑपरेटिंग सिस्टम सिंक्रोनाइज़ेशन की वस्तुएं (महत्वपूर्ण खंड, म्यूटेक्स, सेमीफोर, ईवेंट, आदि), स्पिन लॉक, आदि।
2) एक बहु-थ्रेडेड एप्लिकेशन के कोड का विश्लेषण करना मुश्किल है।
बहु-थ्रेडेड एप्लिकेशन की कठिनाइयों में से एक यह है कि बहु-थ्रेडेड एप्लिकेशन के कोड को देखते समय यह स्पष्ट रूप से स्पष्ट नहीं है कि क्या किसी विशेष विधि को विभिन्न थ्रेड्स से (या कॉल) कहा जा सकता है। यानी आपको ध्यान रखना होगा कि विभिन्न थ्रेड्स से कौन से तरीके कहे जा सकते हैं और कौन से नहीं। चूंकि पूरी तरह से सभी विधियों को थ्रेड-सेफ बनाना एक विकल्प नहीं है, इसलिए हमेशा एक ऐसी विधि को कॉल करके त्रुटि में चलाने का मौका होता है जो कई थ्रेड्स से थ्रेड-सुरक्षित नहीं होती है।
3) बहु-थ्रेडेड एप्लिकेशन को डीबग करना मुश्किल है।
एक बहु-थ्रेडेड अनुप्रयोग में, थ्रेड्स की एक निश्चित स्थिति के साथ बहुत सी त्रुटियां हो सकती हैं जो समानांतर में चल रही हैं (एक नियम के रूप में, विभिन्न थ्रेड्स में निष्पादित कमांड के अनुक्रम के साथ)। एक दिलचस्प उदाहरण यहाँ वर्णित है (http://www.thedelphigeek.com/2011/08/multithreading-is-hard.html)। ऐसी स्थिति को कृत्रिम रूप से बनाना बहुत मुश्किल है, लगभग असंभव है। इसके अलावा, डेल्फी में बहु-थ्रेडेड अनुप्रयोगों को डीबग करने के लिए बहुत सारे उपकरण नहीं हैं, विज़ुअल स्टूडियो इस संबंध में एक स्पष्ट नेता है।
4) एक बहु-थ्रेडेड एप्लिकेशन में, त्रुटियों को संभालना मुश्किल है।
यदि एप्लिकेशन में एक ग्राफिकल यूजर इंटरफेस है, तो केवल एक धागा उपयोगकर्ता के साथ बातचीत कर सकता है। आमतौर पर, जब एप्लिकेशन में किसी प्रकार की त्रुटि होती है, तो हम या तो इसे एप्लिकेशन के अंदर संसाधित करते हैं या उपयोगकर्ता को संदेश प्रदर्शित करते हैं। यदि त्रुटि एक अतिरिक्त स्ट्रीम में होती है, तो वह उपयोगकर्ता को "तुरंत" कुछ भी नहीं कह सकता है। तदनुसार, आपको त्रुटि को अतिरिक्त स्ट्रीम में सहेजना होगा जब तक कि यह मुख्य स्ट्रीम के साथ सिंक्रनाइज़ नहीं किया जाता है और केवल तब इसे उपयोगकर्ता को जारी करता है। इससे अपेक्षाकृत जटिल और भ्रामक कोड संरचना हो सकती है।

क्या मेरे जीवन को थोड़ा सरल करने का कोई तरीका है?

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

मुझे ओटीएल जानकारी कहां मिल सकती है?

• इस मंच में।
• पुस्तकालय के लेखक के ब्लॉग में ।
• GoogleCode में प्रोजेक्ट पृष्ठ पर।

इसके अलावा, पुस्तकालय के लेखक अब ओमनीथ्रिडलिफ्ट्स और मल्टीथ्रेडिंग के बारे में विकी-बुक भर रहे हैं, अधिकांश उच्च-स्तरीय ओटीएल प्राइमिटिव्स के बारे में लेख तैयार हैं।

ओटीएल क्या सुविधाएँ प्रदान करता है?

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

भविष्य

यह आदिम आपको एक अतुल्यकालिक फ़ंक्शन कॉल करने और सही समय पर गणना के पूरा होने और निष्पादन का परिणाम प्राप्त करने की अनुमति देता है। इस आदिम की मदद से, किसी भी प्रक्रिया या फ़ंक्शन के लिए कॉल को आसानी से अतुल्यकालिक में बदल दिया जा सकता है।
यह कुछ इस तरह दिखता है:

uses OtlParallel; ... procedure TestFuture; var vFuture: IOmniFuture<integer>; begin //      vFuture := Parallel.Future<integer>( function: integer var i: integer; begin Result := 0; for i := 1 to 100000 do Result := Result + i; end ); //   -     (      (    ,    ,        ) //     ,     ShowMessage(IntToStr(vFuture.Value)); end; 

कृपया ध्यान दें कि यह vFuture.Value के लिए कॉल है जो अतिरिक्त एक के साथ मुख्य धारा के सिंक्रनाइज़ेशन का क्षण है, अर्थात्। जब तक हम मूल्य की ओर मुड़ते हैं, तब तक हमें दूसरे धागे की स्थिति के बारे में कुछ नहीं पता है जैसे ही हम मूल्य कहते हैं, मुख्य धागा तब तक निलंबित रहता है जब तक कि गणना अतिरिक्त धागे में पूरी नहीं हो जाती।

यदि आवश्यक हो, तो आप मुख्य धागे में परिणाम के लिए एक गैर-अवरुद्ध प्रतीक्षा को लागू कर सकते हैं:

 while not vFuture.IsDone do Application.ProcessMessages; 

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

पाइपलाइन

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

 uses OtlCommon, OtlCollections, OtlParallel; var sum: integer; begin sum := Parallel.Pipeline .Stage( procedure (const input, output: IOmniBlockingCollection) var i: integer; begin for i := 1 to 1000000 do output.Add(i); end) .Stage( procedure (const input: TOmniValue; var output: TOmniValue) begin output := input.AsInteger * 3; end) .Stage( procedure (const input, output: IOmniBlockingCollection) var sum: integer; value: TOmniValue; begin sum := 0; for value in input do Inc(sum, value); output.Add(sum); end) .Run.Output.Next; end; 

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

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

निष्कर्ष

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

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