🗳️ 🤲🏼 ❔ .NET में रैंडम नंबर जनरेशन 🐽 🤳🏿 🏈

लेख का अनुवाद रैंडम संख्याएँ व्यापक रूप से जॉन स्कीट द्वारा संकीर्ण वृत्तों में जाना जाता है। मैं इस लेख पर रुक गया, क्योंकि एक समय मैं स्वयं इसमें वर्णित समस्या का सामना कर चुका था।

StackOverflow वेबसाइट पर .NET और C # विषयों के माध्यम से देखते हुए, आप "यादृच्छिक" शब्द का उल्लेख करते हुए अनगिनत प्रश्न देख सकते हैं, जो अनिवार्य रूप से एक ही शाश्वत और "अनजाने" प्रश्न को उठाता है: क्यों System.Random यादृच्छिक संख्या जनरेटर "नहीं" काम करता है "और" इसे कैसे ठीक करें "। यह लेख इस समस्या पर विचार करने और इसे हल करने के लिए समर्पित है।

समस्या कथन

समाचार समूह और समाचार पत्र में StackOverflow पर, "यादृच्छिक" विषय के बारे में सभी प्रश्न कुछ इस तरह से हैं:

मैं कई यादृच्छिक संख्याएँ उत्पन्न करने के लिए Random.Next का उपयोग करता हूँ, लेकिन विधि उसी संख्या को लौटाती है जब इसे कई बार कहा जाता है। अनुप्रयोग शुरू होने पर हर बार नंबर बदलता है, हालांकि, यह एक प्रोग्राम निष्पादन के भीतर स्थिर है।

कोड के एक उदाहरण के रूप में, लगभग निम्नलिखित दिए गए हैं:

//  !  ! for (int i = 0; i < 100; i++) { Console.WriteLine(GenerateDigit()); } ... static int GenerateDigit() { Random rng = new Random(); // ,     return rng.Next(10); }

तो यहाँ क्या गलत है?

व्याख्या

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

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

तो उपरोक्त कोड में क्या गलत है? बुरी खबर यह है कि हम लूप के प्रत्येक पुनरावृत्ति के अंदर रैंडम वर्ग के एक नए उदाहरण का उपयोग कर रहे हैं। रैंडम कंस्ट्रक्टर, जो मापदंडों को स्वीकार नहीं करता है , वर्तमान तिथि और समय के मूल्य को बीज (प्रारंभिक स्थिति) के रूप में लेता है। लूप में परिवर्तन "स्क्रॉल" इतनी तेजी से होता है कि सिस्टम का समय "बदलने का समय नहीं होता है" इसके अंत में; इस प्रकार, रैंडम के सभी उदाहरणों को प्रारंभिक राज्य के समान मूल्य प्राप्त होगा और इसलिए वही छद्म यादृच्छिक संख्या लौटाएगा।

इसे कैसे ठीक करें?

समस्या के कई समाधान हैं, प्रत्येक अपने स्वयं के पेशेवरों और विपक्षों के साथ। हम उनमें से कुछ पर विचार करेंगे।

एक क्रिप्टोग्राफिक यादृच्छिक संख्या जनरेटर का उपयोग करना

.NET में सार वर्ग randomNumberGenerator शामिल है , जहाँ से क्रिप्टोग्राफ़िक यादृच्छिक संख्या जनरेटर के सभी कार्यान्वयन (बाद में क्रिप्टो- आरएनजी के रूप में संदर्भित) को विरासत में मिलना चाहिए। .NET में इन कार्यान्वयनों में से एक भी शामिल है - RNGCryptoServiceProvider वर्ग को पूरा करें। क्रिप्टो-आरएनजी का विचार यह है कि भले ही यह अभी भी एक छद्म यादृच्छिक संख्या जनरेटर है, यह परिणामों के काफी मजबूत अप्रत्याशितता प्रदान करता है। RNGCryptoServiceProvider एंट्रॉपी के कई स्रोतों का उपयोग करता है, जो वास्तव में आपके कंप्यूटर में "शोर" हैं, और यह उत्पन्न होने वाले संख्याओं का अनुक्रम भविष्यवाणी करना बहुत मुश्किल है। इसके अलावा, "इंट्रा-कंप्यूटर" शोर का उपयोग न केवल एक प्रारंभिक अवस्था के रूप में किया जा सकता है, बल्कि निम्न यादृच्छिक संख्याओं के कॉल के बीच भी किया जा सकता है; इस प्रकार, कक्षा की वर्तमान स्थिति को जानते हुए भी, यह भविष्य में उत्पन्न होने वाली दोनों अगली संख्याओं की गणना करने के लिए पर्याप्त नहीं है और जो पहले उत्पन्न हुई थीं। दरअसल, सटीक व्यवहार कार्यान्वयन पर निर्भर है। इसके अलावा, विंडोज विशेष हार्डवेयर का उपयोग कर सकता है जो "सच्ची दुर्घटनाओं" का स्रोत है (उदाहरण के लिए, यह एक रेडियोधर्मी आइसोटोप का एक क्षय सेंसर हो सकता है) और भी अधिक सुरक्षित और विश्वसनीय यादृच्छिक संख्या उत्पन्न करने के लिए।

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

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

हालांकि, ज्यादातर मामलों में, रैंडम वर्ग की "कमजोरी" काफी उपयुक्त है यदि आप लेख की शुरुआत में वर्णित समस्या को हल कर सकते हैं। आइए देखें कि यहां क्या किया जा सकता है।

कई कॉल के लिए रैंडम क्लास के एक उदाहरण का उपयोग करें

यहाँ यह है, समस्या के समाधान की जड़ रैंडम के केवल एक उदाहरण का उपयोग करना है जब रैंडम का उपयोग करके कई रैंडम नंबर बनाए जाते हैं। और यह बहुत सरल है - देखें कि आप उपरोक्त कोड कैसे बदल सकते हैं:

 //     Random rng = new Random(); for (int i = 0; i < 100; i++) { Console.WriteLine(GenerateDigit(rng)); } ... static int GenerateDigit(Random rng) { // ,     return rng.Next(10); }

अब, प्रत्येक पुनरावृत्ति की अलग-अलग संख्याएँ होंगी ... लेकिन यह सब नहीं है। यदि हम एक पंक्ति में दो बार कोड के इस ब्लॉक को कॉल करते हैं तो क्या होगा? यह सही है, हम एक ही प्रारंभिक मूल्य के साथ यादृच्छिक के दो उदाहरण बनाएंगे और यादृच्छिक संख्या के दो समान सेट प्राप्त करेंगे। प्रत्येक सेट में, संख्या अलग-अलग होगी, हालांकि, इन सेटों के बीच समान होगा।

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

धागा सुरक्षा

रैंडम क्लास थ्रेड सुरक्षित नहीं है। यह देखते हुए कि हम कैसे एक उदाहरण बनाना पसंद करते हैं और पूरे निष्पादन के दौरान पूरे कार्यक्रम में इसका उपयोग करते हैं (सिंगलटन, हैलो!), थ्रेड सुरक्षा की कमी एक वास्तविक दर्द बन जाती है। आखिरकार, यदि हम एक ही समय में कई थ्रेड्स में एक ही उदाहरण का उपयोग करते हैं, अर्थात्, इसकी आंतरिक स्थिति को शून्य करने की संभावना है, और यदि ऐसा होता है, तो उस क्षण से उदाहरण बेकार हो जाएगा।

फिर, समस्या को हल करने के दो तरीके हैं। पहले तरीके में अभी भी एक उदाहरण का उपयोग शामिल है, लेकिन इस बार मॉनिटर के माध्यम से संसाधन लॉक का उपयोग करना। ऐसा करने के लिए, रैंडम के चारों ओर एक आवरण बनाएं, जो लॉक स्टेटमेंट में अपने तरीकों के कॉल को लपेट देगा, जो कॉल करने वाले के लिए विशेष पहुंच प्रदान करता है। यह तरीका खराब है क्योंकि यह बहु-थ्रेडेड-गहन परिदृश्यों में प्रदर्शन को कम करता है।

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

सुरक्षित प्रदाता

सौभाग्य से, .NET 4 में पेश किया गया नया जेनेरिक थ्रेडलोकल <T> वर्ग, उन प्रदाताओं को लिखना बहुत आसान बनाता है जो प्रत्येक थ्रेड के लिए एक उदाहरण प्रदान करते हैं। आपको थ्रेडलोक कंस्ट्रक्टर को एक प्रतिनिधि को पास करना होगा, जो हमारे उदाहरण के मूल्य को प्राप्त करने के लिए संदर्भित करेगा। इस मामले में, मैंने एक एकल प्रारंभिक मूल्य (बीज) का उपयोग करने का फैसला किया, इसे पर्यावरण के साथ आरंभ किया। टिककाउंट (यह बिना मापदंडों के रैंडम कंस्ट्रक्टर कैसे काम करता है)। इसके अलावा, हर बार एक अलग स्ट्रीम के लिए रैंडम की संख्या बढ़ जाती है, हमें रैंडम का नया उदाहरण प्राप्त करने की आवश्यकता होती है।

नीचे दिया गया वर्ग पूरी तरह से स्थिर है और इसमें केवल एक सार्वजनिक (सार्वजनिक) GetThreadRandom विधि शामिल है। यह विधि एक विधि द्वारा बनाई गई है, संपत्ति नहीं, मुख्य रूप से सुविधा के कारण: इसके लिए धन्यवाद, सभी वर्गों को एक यादृच्छिक उदाहरण की आवश्यकता है जो फंक <रैंडम> पर निर्भर करेगा (एक प्रतिनिधि जो उस पद्धति को इंगित करता है जो कोई पैरामीटर नहीं लेता है और प्रकार का मान लौटाता है) रैंडम क्लास से ही नहीं। यदि प्रकार को एक धागे में काम करने के लिए डिज़ाइन किया गया है, तो यह एक प्रतिनिधि को रैंडम का एक भी उदाहरण प्राप्त करने के लिए बुला सकता है और फिर हर जगह इसका उपयोग कर सकता है; यदि प्रकार को बहु-थ्रेडेड परिदृश्यों में काम करना चाहिए, तो यह हर बार एक प्रतिनिधि को कॉल कर सकता है, जिसे यादृच्छिक संख्या जनरेटर की आवश्यकता होती है। नीचे का वर्ग रैंडम वर्ग के कई उदाहरणों के रूप में पैदा करेगा क्योंकि थ्रेड्स हैं, और प्रत्येक उदाहरण एक अलग प्रारंभिक मूल्य से शुरू होगा। यदि हमें यादृच्छिक संख्या प्रदाता को अन्य प्रकारों में निर्भरता के रूप में उपयोग करने की आवश्यकता है, तो हम यह कर सकते हैं: new TypeThatNeedsRandom(RandomProvider.GetThreadRandom) । ठीक है, यहाँ कोड ही है:

 using System; using System.Threading; public static class RandomProvider { private static int seed = Environment.TickCount; private static ThreadLocal<Random> randomWrapper = new ThreadLocal<Random>(() => new Random(Interlocked.Increment(ref seed)) ); public static Random GetThreadRandom() { return randomWrapper.Value; } }

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

इंटरफ़ेस डिज़ाइन समस्याएँ

एक समस्या अभी भी बनी हुई है: हम एक कमजोर संरक्षित यादृच्छिक संख्या जनरेटर का उपयोग करते हैं। जैसा कि पहले उल्लेख किया गया है, रैंडम नम्बरगैनेर में सभी मामलों में RNG का अधिक सुरक्षित संस्करण है, जिसका कार्यान्वयन RNGCryptoServiceProvider वर्ग में है। हालांकि, मानक स्क्रिप्ट में इसका एपीआई उपयोग करना काफी कठिन है।

यह बहुत अच्छा होगा अगर फ्रेमवर्क में RNG प्रदाताओं के पास "यादृच्छिकता के स्रोत" अलग थे। इस मामले में, हमारे पास एक एकल सरल और सुविधाजनक एपीआई हो सकता है जो एक असुरक्षित-लेकिन-तेज़ कार्यान्वयन और सुरक्षित-लेकिन धीमी गति से दोनों का समर्थन करेगा। वैसे सपने देखना बुरा नहीं है। शायद यह कार्यक्षमता .NET फ्रेमवर्क के भविष्य के संस्करणों में दिखाई देगी। शायद Microsoft का कोई व्यक्ति एडॉप्टर के अपने कार्यान्वयन की पेशकश नहीं करेगा। (दुर्भाग्य से, मैं यह कोई नहीं होगा ... इस तरह के विचार का सही कार्यान्वयन आश्चर्यजनक रूप से जटिल है।) आप इसे रैंडम से विरासत में प्राप्त करके और नमूना और नेक्स्टबाइट के तरीकों को फिर से परिभाषित करके अपनी खुद की कक्षा भी बना सकते हैं, हालांकि यह स्पष्ट नहीं है कि वे कैसे काम करते हैं, और यहां तक कि अपना भी। नमूना कार्यान्वयन लगता है की तुलना में बहुत अधिक जटिल हो सकता है। शायद अगली बार ...

.NET में रैंडम नंबर जनरेशन