धागे के साथ काम करने का मेरा "प्रतिमान"

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

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

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

थ्रेड सेफ ऑब्जेक्ट

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

अवरुद्ध

विवरण

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

उदाहरण

इस स्थिति को समझना और कड़ाई से पालन करना गतिरोध की अनुपस्थिति की कुंजी है। आइए एक उदाहरण देखें कि मैं किस बारे में बात कर रहा हूं। मान लीजिए कि हमारे पास कुछ वर्ग हैं:

TMyObj = class private FCS: TCriticalSection; FA: Integer; FB: Integer; public property A: Integer read GetA write SetA; property B: Integer read GetB write SetB; function DoSomething: Integer; //...  end; 

हमारे पास एक थ्रेड सेफ ऑब्जेक्ट क्या होना चाहिए - मैंने गेटर्स के माध्यम से ए और बी गुणों को लागू किया और एक महत्वपूर्ण खंड के साथ बसता है:

 function TMyObj.GetA: Integer; begin FCS.Enter; try Result := FA; finally FCS.Leave; end; end; function TMyObj.GetB: Integer; begin FCS.Enter; try Result := FB; finally FCS.Leave; end; end; procedure TMyObj.SetA(const Value: Integer); begin FCS.Enter; try FA := Value; finally FCS.Leave; end; end; procedure TMyObj.SetB(const Value: Integer); begin FCS.Enter; try FB := Value; finally FCS.Leave; end; end; 

मान लें कि DoSomething फ़ंक्शन A और B के साथ इस तरह काम करता है:

 function TMyObj.DoSomething: Integer; begin Result := SendMessage(SomeHandle, WM_MYMESSAGE, A mod 3, B mod 4); end; 

अरे, लेकिन हम ए और बी के लिए एक महत्वपूर्ण खंड का उपयोग करते हैं, अनुभवहीन लेखक कहेंगे। और तुरंत इस टुकड़े का "अनुकूलन" करता है:

 function TMyObj.DoSomething: Integer; begin FCS.Enter; try Result := SendMessage(SomeHandle, WM_MYMESSAGE, FA mod 3, FB mod 4); finally FCS.Leave; end; end; 

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

 function TMyObj.DoSomething: Integer; var k, n: Integer; begin FCS.Enter; try k := FA mod 3; n := FB mod 4; finally FCS.Leave; end; Result := SendMessage(SomeHandle, WM_MYMESSAGE, k, n); end; 

इसलिए, हमेशा, एक नया सिंक्रनाइज़ेशन कॉल करने से पहले - आपको अन्य सिंक्रनाइज़ेशन ऑब्जेक्ट्स को मुक्त करने की आवश्यकता है। की भावना में कोड:

 FCS1.Enter; try //bla bla bla FCS2.Enter; try //bla bla bla finally FCS2.Leave; end; //bla bla bla finally FCS1.Leave; end; 

ज्यादातर मामलों में, इसे बहु-थ्रेडेड बाय-कोड माना जा सकता है। मुझे लगता है कि आप पहले से ही कल्पना करते हैं कि इसे कैसे फिर से लिखना है:

 FCS1.Enter; try //bla bla bla //bla bla bla //  / ,       FCS2 finally FCS1.Leave; end; FCS2.Enter; try //   / //bla bla bla finally FCS2.Leave; end; 

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

निदान

संकलन स्तर पर, इसका निदान नहीं किया जा सकता है। हालांकि, वास्तविक समय में निदान करना संभव है। ऐसा करने के लिए, हमें प्रत्येक थ्रेड के लिए वर्तमान सिंक्रनाइज़ेशन ऑब्जेक्ट को संग्रहीत करने की आवश्यकता है। यहाँ डेल्फी पर एक नैदानिक ​​उपकरण का एक उदाहरण कार्यान्वयन है।

 procedure InitSyncObject; procedure PushSyncObject(handle: Cardinal); overload; procedure PushSyncObject(obj: TObject); overload; procedure PopSyncObject; implementation threadvar syncobj: Cardinal; synccnt: Cardinal; procedure InitSyncObject; begin syncobj := 0; synccnt := 0; end; procedure PushSyncObject(handle: Cardinal); begin if handle = 0 then raise EProgrammerNotFound.Create('   '); if (syncobj <> 0) and (handle <> syncobj) then raise EProgrammerNotFound.Create('       '); syncobj := handle; inc(synccnt); end; procedure PushSyncObject(obj: TObject); begin PushSyncObject(Cardinal(obj)); end; procedure PopSyncObject; begin if (syncobj = 0) or (synccnt = 0) then raise EProgrammerNotFound.Create('   '); Dec(synccnt); if synccnt = 0 then syncobj := 0; end; 

जब हम एक नया सूत्र शुरू करते हैं तो हम InitSyncObject कहते हैं।
सिंक्रनाइज़ेशन ऑब्जेक्ट को कैप्चर करने से पहले, PushThreadObject को कॉल करें, सिंक्रोनाइज़ेशन ऑब्जेक्ट को रिलीज़ करने के बाद, PopThreadObject को कॉल करें।
इन कार्यों का उपयोग करने की सुविधा के लिए, मैं SyncObjs.pas मॉड्यूल के कोड को एक नए में कॉपी करने की सलाह देता हूं, SyncObjsDbg.pas कहते हैं। इसमें सिंक्रनाइज़ेशन ऑब्जेक्ट का आधार वर्ग है:

  TSynchroObject = class(TObject) public procedure Acquire; virtual; procedure Release; virtual; end; 

मोल-तोल में PushSyncObject (Self), और रिलीज़ पॉपसंकऑब्जेक्ट में कॉल जोड़ें। इसके अलावा, ThandleObject के साथ इन फ़ंक्शन में WaitFor विधियों को फ़्रेम करना न भूलें। इसके अलावा, अगर हम TThread.Synchronize विधि का उपयोग करते हैं, तो कॉल से पहले हम TThread ऑब्जेक्ट को सहेजते हैं, और इसके बाद हम इसे (PopSyncObject) को पुनः प्राप्त करते हैं, अगर हम SendMessage API या WaitFor फ़ंक्शन का उपयोग करते हैं, तो कॉल से पहले हम हैंडल (PushSyncObject) को सहेजते हैं, उसके बाद हम निकालते हैं (PopSyncObject)।
यह सब है, अब जब आप दूसरी सिंक्रनाइज़ेशन ऑब्जेक्ट को पकड़ने की कोशिश करते हैं, तो एक अपवाद उठाया जाएगा, और मॉड्यूल (SyncObjs / SyncObjsDbg) को परिभाषित के माध्यम से बदला जा सकता है।

बुरा कोड

उदाहरण के रूप में बुरा कोड लें ... Class.pas मॉड्यूल से TThreadList वर्ग

  TThreadList = class private FList: TList; FLock: TRTLCriticalSection; FDuplicates: TDuplicates; public constructor Create; destructor Destroy; override; procedure Add(Item: Pointer); procedure Clear; function LockList: TList; procedure Remove(Item: Pointer); inline; procedure RemoveItem(Item: Pointer; Direction: TList.TDirection); procedure UnlockList; inline; property Duplicates: TDuplicates read FDuplicates write FDuplicates; end; 

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

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

शायद काफी है

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