Windows API के reader/writer lock में पाया गया बग

 (old.reddit.com)
2 पॉइंट द्वारा GN⁺ 2024-03-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Windows में std::shared_mutex में बग की संभावना

  • एक सॉफ़्टवेयर टीम ने Windows में std::shared_mutex से जुड़ा अप्रत्याशित व्यवहार पाया।
  • यह समस्या केवल MSVC में होती है; MinGW या अन्य प्लेटफ़ॉर्म पर नहीं।
  • जब मुख्य thread exclusive lock हासिल करने के बाद कई child threads shared lock हासिल करने की कोशिश करते हैं, तो लगभग 1000 में 1 बार "deadlock" होता है।
  • deadlock होने पर ठीक 1 child thread ही shared lock सफलतापूर्वक हासिल करता है, और बाकी child threads lock_shared() पर हमेशा के लिए block हो जाते हैं।
  • यह समस्या std::shared_mutex, std::shared_lock/std::unique_lock या सीधे SRW functions को कॉल करने पर देखी गई।

कोड उदाहरण और बग का पुनरुत्पादन

  • समस्या को पुनरुत्पादित करने वाला एक सरल कोड उपलब्ध कराया गया है।
  • यह कोड उस प्रक्रिया को दोहराता है जिसमें मुख्य thread exclusive lock हासिल करता है, कई child threads shared lock हासिल करते हैं, और फिर उसे छोड़ते हैं।
  • यह कोड केवल Windows MSVC implementation में std::shared_mutex से जुड़ा बग दिखाता है।

विशेषज्ञों की राय

  • STL developer ने कहा कि यह समस्या Windows API के बग जैसी लगती है।
  • बग रिपोर्ट करने के सही चरणों पर चर्चा हुई, और STL developer ने अंदरूनी रूप से बग रिपोर्ट किया।
  • दूसरे users ने इस समस्या की विस्तार से जाँच की और SRWLock implementation के एक खास बग को सीमित दायरे में पहचानने में योगदान दिया।

GN⁺ की राय

  • यह लेख C++ developers के लिए खास तौर पर महत्वपूर्ण जानकारी देता है, क्योंकि std::shared_mutex में संभावित बग multithreading applications के synchronization mechanism को प्रभावित कर सकता है।
  • यदि बग की पुष्टि होती है, तो इसका असर C++ standard library implementation की विश्वसनीयता पर पड़ सकता है। developers को ऐसे मुद्दों के प्रति जागरूक रहना चाहिए और वैकल्पिक synchronization mechanisms पर विचार करना पड़ सकता है।
  • यह समस्या खासकर high-performance या real-time systems में महत्वपूर्ण हो सकती है, क्योंकि ऐसे systems में deadlock गंभीर परिणाम ला सकता है।
  • इस तकनीक को अपनाने से पहले, developers को संबंधित platform और compiler पर व्यापक testing करनी चाहिए ताकि यह सुनिश्चित किया जा सके कि इस तरह के बग मौजूद नहीं हैं।
  • इस समस्या से निपटने के लिए developers Boost library जैसी वैकल्पिक synchronization libraries पर विचार कर सकते हैं। Boost का व्यापक रूप से परीक्षण किया गया है और यह कई platforms पर उपयोग होती है, इसलिए यह ऐसे मुद्दों के लिए एक स्थिर विकल्प दे सकती है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-04
Hacker News की राय

  • एक उपयोगकर्ता ने यह जानना चाहा कि इतना बुनियादी मुद्दा इतने लंबे समय तक पकड़ में क्यों नहीं आया, और दूसरे उपयोगकर्ता द्वारा दिए गए एक भरोसेमंद जवाब का ज़िक्र किया। उन्होंने बताया कि कुछ मामलों में shared mode में lock लेने की कोशिश करने वाला thread गलती से exclusive mode में lock हासिल कर सकता है। यह तब होता है जब shared mode acquire करने वाला thread और exclusive mode release करने वाला thread एक ही समय पर चल रहे हों, जिससे atomic bit test-and-set operation आपस में overlap कर जाते हैं.

    • एक उपयोगकर्ता ने समझाया कि उनके पास ऐसा reproduction code है जिसमें shared lock हासिल करते समय बाकी सभी thread shared lock हासिल करने का इंतज़ार करते हैं। इस वजह से अगर कोई worker thread गलती से exclusive lock हासिल कर ले, तो deadlock हो सकता है। सामान्य उपयोग के मामलों में thread एक-दूसरे का इंतज़ार नहीं करते, इसलिए deadlock नहीं होता.

  • एक अन्य उपयोगकर्ता ने कहा कि Reader/Writer lock में आने वाले subtle bug उन्हें हैरान नहीं करते, और C++11 तथा std::shared_mutex से पहले Win32 आधारित internal implementation पर काम करने का अपना अनुभव साझा किया। उन्होंने कहा कि shared lock के साथ खराब अनुभवों की वजह से वे उन्हें तब तक टालते हैं जब तक बिल्कुल ज़रूरी न हो.

    • एक उपयोगकर्ता ने shared lock के साथ अपने नकारात्मक अनुभव साझा किए और कहा कि std::shared_mutex का performance, std::mutex की तुलना में काफ़ी खराब था, इसलिए data को double buffering करना ज़्यादा तेज़ निकला.

  • एक उपयोगकर्ता ने बताया कि शीर्षक भ्रामक है, क्योंकि असली bug Windows API के slim reader/writer (SRW) lock में है, और यह इसलिए सामने आया क्योंकि std::shared_mutex को SRW lock का उपयोग करके implement किया गया था। एक Microsoft कर्मचारी ने पुष्टि की कि यह bug अंदरूनी तौर पर Windows API टीम तक पहुँचा दिया गया है.

    • एक उपयोगकर्ता ने भ्रामक शीर्षक की ओर इशारा किया और कहा कि असली समस्या Windows API के SRW lock में है, और एक Microsoft कर्मचारी ने पुष्टि की कि bug को आगे बढ़ाया गया है.

  • एक उपयोगकर्ता ने पूछा कि क्या यही समस्या WINE के implementation में भी आती है, और कहा कि वे अपनी customized XP installation पर भी इसे test करना चाहते हैं। उन्होंने बताया कि उस installation में SRW API सहित कई extension जोड़े गए हैं, और SRW implementation पर आधारित keyed event API में deadlock पैदा करने वाली race condition को ठीक करने के लिए उन्होंने kernel patch किया था.

    • एक उपयोगकर्ता ने पूछा कि क्या WINE implementation में भी यही समस्या आती है, और कहा कि वे अपनी customized XP installation पर इसे test करना चाहते हैं। उन्होंने बताया कि उस installation में SRW API सहित कई extension जोड़े गए हैं और SRW implementation पर आधारित keyed event API में deadlock पैदा करने वाली race condition को ठीक करने के लिए kernel patch किया गया था.

  • यह भी बताया गया कि program में एक bug है। इसमें non-atomic variable और atomic variable को मिलाकर yield() check loop में इस्तेमाल किया गया है, जबकि non-atomic variable दूसरे thread के लिए cache coherence की गारंटी नहीं देता। इसकी वजह से loop हमेशा के लिए चल सकता है.

    • एक उपयोगकर्ता ने program के bug की ओर इशारा किया और समझाया कि non-atomic और atomic variable को मिलाकर इस्तेमाल करने से यह समस्या पैदा होती है। non-atomic variable cache coherence की गारंटी नहीं देते, इसलिए loop अनंत समय तक चल सकता है.

  • एक उपयोगकर्ता ने कहा कि यह bug 2008 के Vista version तक जाता है, और उन्हें हैरानी है कि इतने लंबे समय तक किसी ने इसे पकड़ा नहीं। उन्होंने कहा कि सामान्य rwlock usage में shared lock न मिल पाने के random मामले आ सकते हैं, लेकिन deadlock नहीं होता.

    • एक उपयोगकर्ता ने कहा कि यह bug Vista version तक जाता है और इतने लंबे समय तक इसका पता न चलने पर आश्चर्य जताया। उन्होंने बताया कि सामान्य rwlock usage में deadlock नहीं होता, लेकिन shared lock हासिल न कर पाने के मामले हो सकते हैं.

  • एक उपयोगकर्ता ने कहा कि Windows API में bug report करना बहुत मुश्किल है। उन्हें Feedback Hub के ज़रिए report करने को कहा जाता है, लेकिन उन्होंने इसकी कड़ी आलोचना की कि यह लगभग बेअसर है। उस उपयोगकर्ता ने SRWLOCK से जुड़ा एक bug report किया था, जिसमें exclusive owner द्वारा ownership छोड़ने के बाद कई read thread एक साथ shared ownership लेने की कोशिश करें तो deadlock हो सकता है.

    • एक उपयोगकर्ता ने कहा कि Windows API के लिए bug report करना बहुत कठिन है और Feedback Hub के ज़रिए reporting प्रभावी नहीं है। उन्होंने SRWLOCK से जुड़े bug को report करने की बात साझा की.

  • एक उपयोगकर्ता ने याद किया कि पहले MS product खरीदने पर support incidents मिलते थे, और अगर कोई असली bug मिलता था तो वह support incident refund कर दिया जाता था। उन्होंने कहा कि यह developers के लिए उपयोगी था और MS के लिए भी अच्छा system था, क्योंकि इससे असली समस्याएँ पकड़ने और documentation बेहतर करने के लिए feedback मिलता था। उन्होंने पूछा कि क्या यह program अब भी मौजूद है.

    • एक उपयोगकर्ता ने MS product के साथ मिलने वाले support incidents को याद किया और कहा कि यह system developers और MS दोनों के लिए उपयोगी था। उन्होंने पूछा कि क्या यह program आज भी मौजूद है.

  • अंत में, एक उपयोगकर्ता ने Windows API के लिए bug report करना कठिन होने पर निराशा जताई.

    • एक उपयोगकर्ता ने Windows API के लिए bug reporting की कठिनाई पर निराशा व्यक्त की.