🈂️ 🎑 🧒🏿 लॉकलेस एल्गोरिथम: अस्थिर कैश 💯 🔗 🏄

(तथ्य यह है कि "लॉक-फ़्री" की अवधारणा का रूसी अनुवाद अभी तक साहित्य में स्थापित नहीं हुआ है, मुझे बिल्कुल भी विश्वास नहीं है कि ऐसा अनुवाद नहीं होना चाहिए।)

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

 BOOL IsPrime (int n)
 {
  स्थिर int nLast = 1;
  स्थिर BOL fLastIsPrime = FALSE;

  // यदि पिछली बार से पैरामीटर मान नहीं बदला है,
  // तैयार परिणाम का उपयोग करें
  if (n == nast) वापसी fLastIsPrime;

  // नए परिणाम की गणना करें और याद रखें
  nLast = n;
  fLastIsPrime = slow_IsPrime (n);
  वापसी fLastIsPrime;
 }

बेशक, यह कोड थ्रेड-सुरक्षित है: यदि एक थ्रेड slow_IsPrime() कॉल के अंदर है, तो दूसरा थ्रेड जिसे IsPrime() कहा जाता है, nLast और fLastIsPrime के मूल्यों को एक दूसरे के साथ असंगत बना देगा।

एक सरल समाधान एक महत्वपूर्ण अनुभाग में कोड को घेरना है; लेकिन सादगी प्रदर्शन की कीमत पर है: अगर, कहते हैं, nLast = 5, fLastIsPrime = TRUE, और दो धागे एक साथ IsPrime(5) , तो उन्हें लाइन करने की कोई आवश्यकता नहीं है, कुछ भी उन्हें एक ही समय में कैश्ड मान का उपयोग करने से रोकता है।

आइए देखें कि आप बिना लॉक के हमारे कैश को कैसे लागू कर सकते हैं। हम पिछली पोस्ट से एक बार में दो ट्रिक का उपयोग करेंगे: हर बार डेटा बदलने के बाद संस्करण संख्या को अपडेट करना, और कैश प्रविष्टि को सिंक्रनाइज़ करने के लिए "डू, राइट, (निराशा)" मॉडल।

 # अल्पाइन पृथक (एल) ((एल) और 1)

 BOOL IsPrime (int n)
 {
  स्थिर int nLast = 1;
  स्थिर BOL fLastIsPrime = FALSE;
  स्थिर लंबी lCounter = 0;

  // कैश से मूल्य प्राप्त करने का प्रयास करें
  LONG lCounterStart = InterlockedReadAcquire (& lCounter, -1);
  अगर (IsLocked (lCounterStart) && n == nLast) {
   BOOL fResult = fLastIsPrime;
   // किसी ने हमारे पीछे कैश नहीं छुआ?
   यदि (InterlockedReadRelease (& lCounter, -1) == lCounterStart)
    वापसी;
  }

  // या तो कैश से पढ़ना विफल रहा, या मूल्य फिट नहीं हुआ:
  // सामान्य तरीके से गणना करें
  BOOL fIsPrime = slow_IsPrime (n);

  // कैश में मूल्य को बचाने की कोशिश करें
  lCounterStart = lCounter;
  अगर (IsLocked (lCounterStart) &&)
      InterlockedCompareExchangeAcquire (& lCounter,
               lCounterStart + 1, lCounterStart) == lCounterStart) {
   nLast = n;
   fLastIsPrime = fIsPrime;
   InterlockedCompareExchangeRelease (और lCounter,
               lCounterStart + 2, lCounterStart + 1);
  }
  वापसी fIsPrime;
 }

lCounter में lCounter महत्वपूर्ण बिट का मतलब है कि कैश रिकॉर्डिंग की अवधि के लिए "लॉक" है; शेष बिट्स संस्करण संख्या संग्रहीत करते हैं। ऐसा संगठन एक साधारण ऑपरेशन में संस्करण संख्या को अनलॉक करने और अपडेट करने की अनुमति देता है।

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

दोनों ही मामलों में - यदि कैश्ड परिणाम फिट नहीं हुआ, या यदि पढ़ा गया डेटा अविश्वसनीय हो गया, तो हम बस अपने हाथ को कैश पर लाते हैं जो बेकार हो गया है, और गणनाओं को पूरा करें।

कैश में लिखते समय, हम न केवल यह जांचते हैं कि कैश लॉक नहीं है, बल्कि एक ही समय में इसे स्वयं ब्लॉक भी करें, कम से कम महत्वपूर्ण बिट सेट करें। (यदि यह पता चलता है कि कैश ब्लॉक किया गया था, तो यह भी डरावना नहीं है: अगर हम इसमें परिकलित परिणाम नहीं लिखते हैं तो कोई भी नाराज नहीं होगा। लक्ष्य समय बचाने के लिए है, और पुनर्गणना से बचने के लिए हर कीमत पर नहीं।) कैश को अवरुद्ध करके, हम इसे अपडेट करते हैं। डेटा, और फिर एक ऑपरेशन के साथ InterlockedCompareExchangeRelease लॉक जारी करें और संस्करण संख्या बढ़ाएं। ऑपरेशन रिलीज़ होना चाहिए, ताकि अनलॉक होने से पहले मेमोरी में डेटा परिवर्तन लिखा जाए।

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

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

एक समान प्रणाली TryEnterCriticalSection का उपयोग करके लागू की जा सकती है:

 BOOL IsPrime (int n)
 {
  स्थिर int nLast = 1;
  स्थिर BOL fLastIsPrime = FALSE;
  BOOL fHaveAnswer = FALSE;
  BOOL fIsPrime;

  // कैश से मूल्य प्राप्त करने का प्रयास करें
  अगर (TryEnterCriticalSection (& g_cs)) {
   अगर (n == nLast) {
    fHaveAnswer = TRUE;
    fIsPrime = fLastIsPrime;
   }
   लीव क्रिटिसलाईट (& g_cs);
  }
  अगर (fHaveAnswer) वापसी fIsPrime;

  // या तो महत्वपूर्ण खंड व्यस्त है, या मूल्य फिट नहीं है:
  // सामान्य तरीके से गणना करें
  fIsPrime = slow_IsPrime (n);

  // कैश में मूल्य को बचाने की कोशिश करें
  अगर (TryEnterCriticalSection (& g_cs)) {
   nLast = n;
   fLastIsPrime = fIsPrime;
   लीव क्रिटिसलाईट (& g_cs);
  }
  वापसी fIsPrime;
 }

पहला तरीका बेहतर है क्योंकि कैश से पढ़ने वाले धागे एक दूसरे के साथ हस्तक्षेप नहीं करते हैं; महत्वपूर्ण अनुभाग का उपयोग करते समय एक साथ रीडिंग असंभव हैं।

विंडोज 7 से शुरू करके, हम स्लिम रीडर-राइटर लॉक को भी सक्षम कर सकते हैं:

 BOOL IsPrime (int n)
 {
  स्थिर int nLast = 1;
  स्थिर BOL fLastIsPrime = FALSE;
  BOOL fHaveAnswer = FALSE;
  BOOL fIsPrime;

  // कैश से मूल्य प्राप्त करने का प्रयास करें
  अगर (TryAcquireSRWLockSared (& g_lock)) {
   अगर (n == nLast) {
    fHaveAnswer = TRUE;
    fIsPrime = fLastIsPrime;
   }
   रिलीज़स्वरलॉकशेयर (& g_lock);
  }
  अगर (fHaveAnswer) वापसी fIsPrime;

  // या तो कैश लेखन के लिए बंद है, या मूल्य फिट नहीं था:
  // सामान्य तरीके से गणना करें
  fIsPrime = slow_IsPrime (n);

  // कैश में मूल्य को बचाने की कोशिश करें
  अगर (TryAcquireSRWLockExclusive (& g_lock)) {
   nLast = n;
   fLastIsPrime = fIsPrime;
   लीव्सवर्लॉकएक्सक्लूसिव (& g_lock);
  }
  वापसी fIsPrime;
 }

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

लॉकलेस एल्गोरिथम: अस्थिर कैश

More articles: