कंपाइलर ने मेरे सशर्त लूप को अनंत में क्यों बदल दिया?

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

#include <windows.h> int x = 0, y = 1; int* ptr; DWORD CALLBACK ThreadProc(void*) { Sleep(1000); ptr = &y; return 0; } int main(int, char**) { ptr = &x; // starts out pointing to x DWORD id; HANDLE hThread = CreateThread(nullptr, 0, ThreadProc, 0, &id); // ,        ptr //     while (*ptr == 0) { } return 0; } 

जो लोग Windows प्लेटफ़ॉर्म के लिए विशिष्ट सुविधाओं से परिचित नहीं हैं, उनके लिए यहाँ शुद्ध C ++ में बराबर है:

 #include <chrono> #include <thread> int x = 0, y = 1; int* ptr = &x; void ThreadProc() { std::this_thread::sleep_for(std::chrono::seconds(1)); ptr = &y; } int main(int, char**) { ptr = &x; // starts out pointing to x std::thread thread(ThreadProc); // ,        ptr //     while (*ptr == 0) { } return 0; } 

अगला, उपयोगकर्ता कार्यक्रम की अपनी समझ लाया:

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

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

इस प्रश्न का उत्तर देने से पहले, आइए थोड़ा नाइट-पिकिंग से शुरू करें: "वाष्पशील int * ptr" ptr वैरिएबल को "पॉइंटर जिसके लिए ऑप्टिमाइज़ेशन निषिद्ध है" घोषित नहीं करता है। यह "एक चर के लिए सामान्य सूचक है जिसके लिए अनुकूलन प्रतिबंधित हैं।" उपरोक्त प्रश्न के लेखक के मन में "int * volatile ptr" के रूप में घोषित किया जाना था।

अब मुख्य प्रश्न पर वापस आते हैं। यहाँ क्या हो रहा है?

यहां तक ​​कि कोड पर एक त्वरित नज़र हमें बताएगी कि std :: atomic जैसे न तो कोई चर हैं, न ही std का उपयोग: memory_order (या तो स्पष्ट या अंतर्निहित)। इसका मतलब यह है कि दो अलग-अलग धाराओं से ptr या * ptr तक पहुंचने के किसी भी प्रयास से अपरिभाषित व्यवहार होता है। सहज रूप से, आप इसे इस तरह से सोच सकते हैं: "कंपाइलर प्रत्येक थ्रेड को अनुकूलित करता है जैसे कि वह प्रोग्राम में अकेले चल रहा था। एकमात्र बिंदु जहां संकलक MUST को विभिन्न धाराओं के डेटा तक पहुंचने के बारे में सोचते हैं, वे std :: atomic या std या "modorder" का उपयोग कर रहे हैं। "

यह बताता है कि प्रोग्रामर ने अपेक्षा के अनुरूप व्यवहार क्यों नहीं किया। पल से आप अस्पष्ट व्यवहार की अनुमति देते हैं - बिल्कुल कुछ भी गारंटी नहीं दी जा सकती है।

लेकिन ठीक है, आइए उनके प्रश्न के दूसरे भाग के बारे में सोचते हैं: संकलक इस स्थिति को पहचानने के लिए पर्याप्त स्मार्ट क्यों नहीं है और रजिस्टर में पॉइंटर मान को लोड करके स्वतः अनुकूलन बंद कर देता है? खैर, कंपाइलर स्वचालित रूप से सभी संभव लागू करता है और अनुकूलन मानक के विपरीत नहीं है। उसे प्रोग्रामर के विचारों को पढ़ने और मानक के विपरीत नहीं होने वाले कुछ अनुकूलन बंद करने की आवश्यकता होती है, जो प्रोग्रामर के अनुसार, बेहतर के लिए कार्यक्रम के तर्क को बदलना चाहिए। “ओह, क्या होगा अगर यह चक्र किसी अन्य धागे में एक वैश्विक चर के मूल्य में बदलाव की उम्मीद करता है, हालांकि यह स्पष्ट रूप से घोषित नहीं किया गया है? मैं इस स्थिति के लिए तैयार होने के लिए इसे धीमा करने के लिए इसे सौ बार ले जाऊंगा! " क्या ऐसा होना चाहिए? शायद ही।

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

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

 int limit; void do_something() { ... if (value > limit) value = limit; //   limit ... for (i = 0; i < 10; i++) array[i] = limit; //   limit ... } 

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

तो कृपया बस इतना ही करें।