क्या अस्थिरता आवश्यक है?

Question

संपादित और जोहान्स के मूल्यवान जवाब के बाद मेरे सवाल का परिष्कृत

bool b = true; 
volatile bool vb = true;  
void f1() { } 
void f2() { b = false; } 

void(* volatile pf)() = &f1; //a volatile pointer to function 

int main() 
{ 
    //different threads start here, some of which may change pf 
    while(b && vb) 
    { 
     pf(); 
    } 
} 

तो चलिए थोड़ी देर के लिए तुल्यकालन भूल करते हैं। सवाल यह है कि बी को अस्थिर घोषित किया जाना है या नहीं। मैंने अस्थिर अर्थशास्त्र की औपचारिक परिभाषा को मानक और क्रमबद्ध पढ़ा है (मैं उन्हें लगभग समझता हूं, शब्द लगभग कुंजी है)। लेकिन चलो थोड़ा अनौपचारिक हो। यदि संकलक देखता है कि लूप में बी को बदलने के लिए कोई रास्ता नहीं है, तब तक जब तक बी अस्थिर न हो, तो यह इसे अनुकूलित कर सकता है और मान लेता है कि यह while(vb) के बराबर है। सवाल यह है कि, इस मामले में पीएफ स्वयं अस्थिर है, तो क्या संकलक को यह मानने की अनुमति है कि बी लूप में नहीं बदलेगा, भले ही बी अस्थिर न हो?

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

मुझे आशा है कि मेरा प्रश्न स्पष्ट है। TIA

संपादन एक बार फिर:
इस बारे में क्या?

bool b = true; 
volatile bool vb = true; 
void f1() {} 
void f2() {b = false;} 
void (*pf)() = &f1; 

#include <iosrteam> 
int main() 
{ 
    //threads here 

    while(b && vb) 
    { 
     int x; 
     std::cin >> x; 
     if(x == 0) 
     pf = &f1; 
     else 
     pf = &f2;  
     pf(); 
    } 
} 

क्या दो कार्यक्रमों के बीच एक प्रमुख अंतर है। यदि हां, तो क्या अंतर है?

Answer 1

सवाल यह है कि, इस मामले में पीएफ स्वयं अस्थिर है, तो क्या संकलक को यह मानने की अनुमति है कि बी लूप में नहीं बदलेगा, भले ही बी अस्थिर न हो?

यह है क्योंकि आप का कहना है कि pf अन्य थ्रेड द्वारा बदला जा सकता है, और यह परोक्ष रूप से बदलता है bpf अगर जबकि पाश से तो कहा जाता है नहीं कर सकते हैं,। इसलिए, सैद्धांतिक रूप से b पढ़ने के लिए सैद्धांतिक रूप से आवश्यक नहीं है, इसे अभ्यास में यह निर्धारित करने के लिए पढ़ना चाहिए कि इसे शॉर्ट सर्किट होना चाहिए (जब bfalse बन जाता है तो इसे vb किसी अन्य समय नहीं पढ़ना चाहिए)। इसलिए संकलक यह से छुटकारा पाने के लिए और देखने के f1 एक खाली शरीर और f2 सेट गलत पर b है कि कर सकते हैं

---

दूसरे भाग

इस मामले pf में करने के लिए उत्तर नहीं अस्थिर अब, है। के रूप में

int main() 
{ 
    // threads here (which you say can only change "vb") 

    while(vb) 
    { 
     int x; 
     std::cin >> x; 
     if(x != 0) 
     break;  
    } 
} 

---

बड़े संशोधन के जवाब इस प्रकार यह main का अनुकूलन कर सकता है

एक शर्त संकलक पाश अनुकूलन करने के लिए अनुमति दी जा के लिए दूर है कि पाश का उपयोग या किसी अस्थिर संशोधित नहीं करता है ऑब्जेक्ट (देखें [stmt.iter] p5 n3126 में)। आप इसे यहां करते हैं, इसलिए यह लूप को अनुकूलित नहीं कर सकता है। सी ++ 03 में एक कंपाइलर को उस लूप के गैर-अस्थिर संस्करण को अनुकूलित करने की अनुमति नहीं थी (लेकिन संकलक इसे वैसे भी करते थे)।

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

Answer 2

अस्थिर केवल आपको दर्द देता है अगर आपको लगता है कि आप एक अनुकूलन से लाभान्वित हो सकते हैं जो नहीं किया जा सकता है या यदि यह सच है जो सत्य नहीं है।

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

मुझे नहीं पता कि अनुकूलन बचाने के लायक हैं या नहीं, क्योंकि आपने कहा है कि यह वास्तविक कोड नहीं है, लेकिन यदि वे नहीं हैं तो अस्थिरता का उपयोग करने के कोई कारण नहीं हैं।

जब आप गलत व्यवहार में परिणाम प्राप्त करते हैं तो अस्थिरता का उपयोग नहीं करते हैं, क्योंकि अनुकूलन कोड के अर्थ को बदल रहे हैं।

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

Answer 3

इस तरह के मामले में वर्तमान सी ++ मानक में volatile पर सटीक आवश्यकताएं हैं, जैसा कि मैं इसे समझता हूं, मानक द्वारा पूरी तरह से परिभाषित नहीं है, क्योंकि मानक वास्तव में बहु-थ्रेडिंग से निपटता नहीं है। यह मूल रूप से एक संकलक संकेत है। तो, इसके बजाय, मैं एक ठेठ संकलक में क्या होता है पता चलेगा।

सबसे पहले, मान लें कि संकलक स्वतंत्र रूप से आपके कार्यों को संकलित कर रहा है, और फिर उन्हें एक साथ जोड़ रहा है। किसी भी उदाहरण में, आपके पास एक लूप है जिसमें आप एक चर की जांच कर रहे हैं, और फ़ंक्शन पॉइंटर को कॉल कर रहे हैं। उस फ़ंक्शन के संदर्भ में, कंपाइलर को पता नहीं है कि उस फ़ंक्शन पॉइंटर के पीछे फ़ंक्शन क्या करेगा, और इस प्रकार इसे कॉल करने के बाद स्मृति से b को फिर से लोड करना होगा। इस प्रकार, volatile वहां अप्रासंगिक है।

अपना पहला वास्तविक मामले के लिए है कि विस्तार, और संकलक पूरे कार्यक्रम अनुकूलन बनाने के लिए अनुमति देता है, क्योंकि pf अस्थिर संकलक अभी भी पता नहीं क्या यह (यह भी कल्पना नहीं कर सकते यह या तो f1 है पर इंगित किया जा रहा है है या f2!), और इसी प्रकार फ़ंक्शन-पॉइंटर कॉल में अनमोडिफाइड किए जाने के बारे में कोई धारणा नहीं हो सकती है - और b पर अभी भी अप्रासंगिक है।

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

इस प्रकार, संक्षेप में: आपको किसी भी मामले में volatile की आवश्यकता नहीं है।अंतर, जैसा कि एक है, यह है कि पहले मामले में यदि fp अस्थिर नहीं थे, तो पर्याप्त रूप से उन्नत कंपाइलर संभवतः b दूर अनुकूलित कर सकता है, जबकि यह दूसरे मामले में प्रोग्राम में कहीं भी अस्थिर नहीं हो सकता है। प्रैक्टिस में, मुझे उम्मीद नहीं है कि किसी भी कंपाइलर्स वास्तव में उस अनुकूलन को बनाएगा।