सही और गलत की नींद कैसे लें

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

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

void Sleep(DWORD dwMilliseconds); 

बस एक पैरामीटर (बेहद स्पष्ट), कोई त्रुटि कोड या अपवाद नहीं - यह हमेशा काम करता है। बहुत कम ऐसे अच्छे और समझने योग्य कार्य हैं!


क्या गलत हो सकता है? तथ्य यह है कि प्रोग्रामर इस अद्भुत सुविधा का उपयोग करते हैं, यह उस उद्देश्य के लिए नहीं है जो इसके लिए है।

और यह कुछ वास्तविक, ठहराव प्रक्रिया द्वारा परिभाषित कुछ बाहरी के सॉफ्टवेयर सिमुलेशन के लिए है।

सही उदाहरण संख्या 1

हम "घड़ी" एप्लिकेशन लिख रहे हैं, जिसमें एक सेकंड में आपको स्क्रीन पर संख्या (या तीर की स्थिति) को बदलने की आवश्यकता होती है। यहां नींद समारोह पूरी तरह से अनुकूल है: हमारे पास स्पष्ट रूप से परिभाषित अवधि (बिल्कुल एक सेकंड) के लिए वास्तव में कुछ नहीं करना है। सोते क्यों नहीं?

सही उदाहरण संख्या 2

हम एक रोटी मशीन के लिए एक चन्द्रमा नियंत्रक लिख रहे हैं। ऑपरेशन एल्गोरिथ्म एक प्रोग्राम द्वारा सेट किया गया है और कुछ इस तरह दिखता है:

1. मोड 1 पर जाएं।
2. इसमें 20 मिनट तक काम करें
3. मोड 2 पर जाएं।
4. इसमें 10 मिनट तक काम करें
5. बंद कर दें।

यहां सब कुछ स्पष्ट है: हम समय के साथ काम करते हैं, यह तकनीकी प्रक्रिया द्वारा निर्धारित किया गया है। नींद का उपयोग स्वीकार्य है।

अब आइए स्लीप के दुरुपयोग के उदाहरणों को देखें।

जब मुझे गलत C ++ कोड के कुछ उदाहरण की आवश्यकता होती है, तो मैं नोटपैड ++ टेक्स्ट एडिटर कोड रिपॉजिटरी में जाता हूं। इसका कोड इतना भयानक है कि कोई भी एंटीपार्टर्न निश्चित रूप से है, मैंने एक बार इस बारे में एक लेख भी लिखा था। नोटपैड ++ ने मुझे इस बार या तो निराश नहीं किया! आइए देखें कि यह नींद का उपयोग कैसे करता है।

खराब उदाहरण संख्या 1

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

 if ((!isMultiInst) && (!TheFirstOne)) { HWND hNotepad_plus = ::FindWindow(Notepad_plus_Window::getClassName(), NULL); for (int i = 0 ;!hNotepad_plus && i < 5 ; ++i) { Sleep(100); hNotepad_plus = ::FindWindow(Notepad_plus_Window::getClassName(), NULL); } if (hNotepad_plus) { ... } ... } 

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

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

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

खराब उदाहरण संख्या 2

 HANDLE hThread = ::CreateThread(NULL, 0, threadTextTroller, &trollerParams, 0, NULL); int sleepTime = 1000 / x * y; ::Sleep(sleepTime); 

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

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

खराब उदाहरण संख्या 3

यहां हम एक पृष्ठभूमि धागा देखते हैं जो कुछ घटनाओं के इंतजार में सो रहा है।

 class CReadChangesServer { ... void Run() { while (m_nOutstandingRequests || !m_bTerminate) { ::SleepEx(INFINITE, true); } } ... void RequestTermination() { m_bTerminate = true; ... } ... bool m_bTerminate; }; 

मुझे यह स्वीकार करना चाहिए कि यह नींद का उपयोग नहीं किया जाता है, बल्कि यहां नींद का उपयोग किया जाता है, जो अधिक बुद्धिमान है और कुछ घटनाओं (जैसे अतुल्यकालिक संचालन के पूरा होने) के लिए इंतजार कर सकता है। लेकिन यह बिल्कुल मदद नहीं करता है! तथ्य यह है कि जबकि (! M_bTerminate) लूप को अनधिकृत रूप से काम करने का पूरा अधिकार है, दूसरे धागे से मांगी गई RequestTermination () विधि को अनदेखा करते हुए, m_bTerminate वैरिएबल को सही करने के लिए। मैंने पिछले लेख में इसके कारणों और परिणामों के बारे में लिखा था। इससे बचने के लिए, आपको थ्रेड्स के बीच सही ढंग से काम करने के लिए गारंटीकृत कुछ का उपयोग करना चाहिए: परमाणु, घटना, या कुछ इसी तरह।

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

खराब उदाहरण संख्या 4

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

 DWORD WINAPI Notepad_plus::backupDocument(void * /*param*/) { ... while (isSnapshotMode) { ... ::Sleep(DWORD(timer)); ... ::PostMessage(Notepad_plus_Window::gNppHWND, NPPM_INTERNAL_SAVEBACKUP, 0, 0); } return TRUE; } 

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

यानी साधारण अपेक्षा के साथ, हम यहां लापता अधिक बुद्धिमान एल्गोरिथ्म को प्रतिस्थापित करते हैं।

खराब उदाहरण संख्या 5

नोटपैड ++ "टेक्स्ट टाइप करें" - अर्थात पत्र सम्मिलन के बीच रुककर मानव पाठ इनपुट का अनुकरण करें। ऐसा लगता है कि इसे "ईस्टर एग" के रूप में लिखा जा सकता है, लेकिन आप इस सुविधा के काम के कुछ प्रकार के साथ आ सकते हैं ( अपवर्क को मूर्ख बनाना, हाँ )।

 int pauseTimeArray[nbPauseTime] = {200,400,600}; const int maxRange = 200; ... int ranNum = getRandomNumber(maxRange); ::Sleep(ranNum + pauseTimeArray[ranNum%nbPauseTime]); ::SendMessage(pCurrentView->getHSelf(), SCI_DELETEBACK, 0, 0); 

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

निष्कर्ष

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