Windows API में reader/writer locks में बग

मूल लेख ↗ Hacker News चर्चा ↗

Windows के slim reader/writer (SRW) locks में एक लंबे समय से मौजूद bug को C++ के `std::shared_mutex` के जरिए उजागर किया गया है, जिसमें shared lock मांगने वाला thread कभी-कभी exclusive access हासिल कर सकता है और कुछ patterns में deadlock पैदा हो सकता है। Commenters का कहना है कि यह व्यवहार संभवतः Vista के समय से है और concurrency primitives में सूक्ष्म implementation choices तथा fairness trade-offs से जुड़ा है, जबकि Wine और ReactOS में वैकल्पिक implementations इससे अप्रभावित दिखते हैं। यह घटना यह भी दिखाती है कि external developers के लिए official channels के माध्यम से low-level Windows bugs रिपोर्ट करना कितना कठिन है, और यह अधिक खुले या बेहतर-रखरखाव वाले ecosystems के साथ तुलना को उभारता है, जिससे कई लोग profiling से लाभ सिद्ध होने तक reader–writer locks से बचना पसंद करते हैं.

Windows SRWLOCK बग और प्रभाव

  • बग Windows के slim reader/writer (SRW) lock में है; Windows पर std::shared_mutex SRW पर आधारित है, इसलिए वह भी इस समस्या को विरासत में लेता है।
  • परिदृश्य: जब कई readers एक साथ shared access पाने की कोशिश कर रहे हों और exclusive owner lock छोड़ दे, तब lock deadlock हो सकता है।
  • एक Microsoft engineer ने पुष्टि की कि एक internal OS bug file किया गया था; इस पर बहस है कि यह व्यवहार implementation bug है या contract पर्याप्त रूप से निर्दिष्ट नहीं है।
  • low-level analysis से व्याख्या: exclusive release में non-atomic sequence के कारण कभी-कभी कोई shared acquirer exclusive lock हासिल कर सकता है या किसी तरह lock को “steal” कर सकता है, जिससे waiters wake नहीं होते।

Reader/writer locks की semantics और design

  • कई commenters का कहना है कि RW locks deceptively complex होते हैं और subtle bugs के प्रति संवेदनशील होते हैं; कुछ लोग तब तक इनसे बचते हैं जब तक profiling लाभ साबित न कर दे।
  • shared mode को एक optimization के रूप में देखा जाता है, न कि यह strict guarantee कि सभी readers हमेशा साथ रह सकते हैं।
  • fairness बनाम performance: SRW locks जानबूझकर unfair हैं ताकि writer starvation से बचा जा सके और context-switch overhead कम हो; इससे late-arriving readers block हो सकते हैं, भले ही मौजूदा readers active हों।
  • चर्चा किए गए वैकल्पिक patterns: double-buffering, finer-grained locking, RCU-like schemes, shared_ptr-based versioning।

Repro program की correctness

  • एक commenter का दावा है कि sample में non-atomic thread count पर data-race है, और सिर्फ वही hang का कारण बन सकता है।
  • अन्य इसका प्रतिवाद करते हैं: thread creation/join एक happens-before relationship स्थापित करता है; x86 पर और std::thread के साथ यह pattern सुरक्षित माना जाता है, और count को constexpr या atomic बनाने से bug समाप्त नहीं होता।
  • thread में आम सहमति “program ठीक है; SRW implementation दोषपूर्ण है” की ओर झुकती है।

Alternative implementations और platforms

  • Windows पर Rust के RwLock और Mutex भी SRW का उपयोग करते हैं; Mutex सुरक्षित है क्योंकि वह केवल exclusive mode का उपयोग करता है।
  • WINE और ReactOS CAS-based designs का उपयोग करते हैं और ऐसा प्रतीत होता है कि उनमें यह bug नहीं है।
  • कुछ लोग अपने स्वयं के SRW/pushlock variants बनाने के अनुभव साझा करते हैं, छोटे data structures के बावजूद complexity पर जोर देते हुए।

Bug reporting और support अनुभव

  • Windows API bugs रिपोर्ट करना बहुत कठिन बताया गया है; Feedback Hub को low-signal माना जाता है।
  • Workarounds में शामिल हैं: “documentation bugs” file करना, GitHub issue trackers (STL के लिए) का उपयोग करना, या social media के माध्यम से engineers से संपर्क करना।
  • तुलना: Linux kernel और कुछ Apple teams को अधिक responsive बताया गया है, जबकि बड़े vendors अक्सर roadmaps और paying customers को प्राथमिकता देते हैं।
  • corporate feedback systems को लेकर व्यापक निराशा: low-quality reports, first-line support scripts, और bug trackers में “shouting into the void” जैसी भावना।