दो परमाणुओं के साथ स्पिन-लॉक के लिए कम प्रतिबंधित मेमोरी ऑर्डरिंग

Question

मेरे पास कुछ अंतराल धागे नियमित अंतराल (लगभग 1 किलोहाट) पर समय-महत्वपूर्ण प्रसंस्करण कर रहे हैं। प्रत्येक चक्र, श्रमिकों को एक कोर करने के लिए जागृत किया जाता है, जिनमें से प्रत्येक (औसत पर) अगले चक्र शुरू होने से पहले पूरा होना चाहिए। वे एक ही वस्तु पर काम करते हैं, जिसे कभी-कभी मुख्य धागे द्वारा संशोधित किया जा सकता है।

class Foo { 
public: 
    void Modify(); 
    void DoWork(SomeContext&); 
private: 
    std::atomic_flag locked = ATOMIC_FLAG_INIT; 
    std::atomic<int> workers_busy = 0; 
}; 

void Foo::Modify() 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; // spin 
    while(workers_busy.load() != 0) ;       // spin 

    // Modifications happen here .... 

    locked.clear(std::memory_order_release); 
} 

void Foo::DoWork(SomeContext&) 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; // spin 
    ++workers_busy; 
    locked.clear(std::memory_order_release); 

    // Processing happens here .... 

    --workers_busy; 
} 

:

दौड़ को रोकने के लिए है, लेकिन वस्तु अगले चक्र से पहले होने के संशोधन की अनुमति देने, मैं रिकॉर्ड करने के लिए कितने धागे अभी भी काम कर रहे एक परमाणु काउंटर के साथ एक स्पिन ताला का इस्तेमाल किया है

यह सभी शेष कार्यों को तुरंत पूरा करने की अनुमति देता है, बशर्ते कम से कम एक धागा शुरू हो गया हो, और अगले चक्र के लिए एक और कार्यकर्ता काम शुरू करने से पहले हमेशा ब्लॉक कर देगा।

atomic_flag को "अधिग्रहण" और "रिलीज" मेमोरी ऑर्डर के साथ एक्सेस किया गया है, जैसा कि सी ++ 11 के साथ स्पिन-लॉक को लागू करने का एक स्वीकार्य तरीका प्रतीत होता है। documentation at cppreference.com के अनुसार:

memory_order_acquire: इस स्मृति आदेश के साथ एक लोड आपरेशन प्रभावित स्मृति स्थान पर अधिग्रहण आपरेशन करता है: कोई स्मृति वर्तमान सूत्र में पहुँचता इस भार से पहले पुनर्क्रमित जा सकता है। यह सुनिश्चित करता है कि अन्य थ्रेड में सभी लिखते हैं जो समान परमाणु चर को छोड़ते हैं, वर्तमान धागे में दिखाई देते हैं।

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

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

मैं क्या जानना चाहता हूं कि मेमोरी ऑर्डरिंग को और आराम दिया जा सकता है क्योंकि इस पैटर्न का दुष्प्रभाव यह है कि मैं एक अन्य परमाणु चर को सिंक्रनाइज़ करने के लिए स्पिन-लॉक म्यूटेक्स का उपयोग कर रहा हूं।

++workers_busy पर कॉल, --workers_busy और workers_busy.load() वर्तमान में सभी में डिफ़ॉल्ट मेमोरी ऑर्डर, memory_order_seq_cst है। यह देखते हुए कि इस परमाणु के लिए एकमात्र दिलचस्प उपयोग Modify() को --workers_busy (जो स्पिन-लॉक म्यूटेक्स द्वारा सिंक्रनाइज़ नहीं किया गया है) को अनवरोधित करना है, क्या "अधिग्रहण" वृद्धि का उपयोग करके समान चर-रिलीज मेमोरी ऑर्डर का उपयोग इस चर के साथ किया जा सकता है ? अर्थात

void Foo::Modify() 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; 
    while(workers_busy.load(std::memory_order_acquire) != 0) ; // <-- 
    // .... 
    locked.clear(std::memory_order_release); 
} 

void Foo::DoWork(SomeContext&) 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; 
    workers_busy.fetch_add(1, std::memory_order_relaxed);   // <-- 
    locked.clear(std::memory_order_release); 
    // .... 
    workers_busy.fetch_sub(1, std::memory_order_release);   // <-- 
} 

यह सही है? क्या इनमें से किसी भी मेमोरी ऑर्डरिंग को आराम से आराम करना संभव है? और क्या इससे कोई फर्क पड़ता है?

Answer 1

Since you say you're targeting x86 only, आप guaranteed strongly-ordered memory anyway हैं; memory_order_seq_cst से बचने के लिए उपयोगी है (यह महंगा और अनावश्यक मेमोरी बाड़ को ट्रिगर कर सकता है), लेकिन उससे परे, अधिकांश अन्य ऑपरेशंस किसी विशेष ओवरहेड को लागू नहीं करेंगे, इसलिए आपको संभवतः गलत कंपाइलर निर्देश रीडरिंग की इजाजत देने के अलावा अतिरिक्त छूट से कुछ भी हासिल नहीं होगा। यह सुरक्षित होना चाहिए, और किसी भी अन्य समाधान की तुलना में कोई धीमी सी ++ 11 एटोमिक्स का उपयोग कर:

void Foo::Modify() 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; 
    while(workers_busy.load(std::memory_order_acquire) != 0) ; // acq to see decrements 
    // .... 
    locked.clear(std::memory_order_release); 
} 

void Foo::DoWork(SomeContext&) 
{ 
    while(locked.test_and_set(std::memory_order_acquire)) ; 
    workers_busy.fetch_add(1, std::memory_order_relaxed); // Lock provides acq and rel free 
    locked.clear(std::memory_order_release); 
    // .... 
    workers_busy.fetch_sub(1, std::memory_order_acq_rel); // No lock wrapping; acq_rel 
} 

पर सबसे बुरा, 86 पर, यह कुछ संकलक आदेश की कमी लगाता है; इसे अतिरिक्त बाड़ या लॉक निर्देशों को लॉन्च नहीं करना चाहिए जिन्हें लॉक करने की आवश्यकता नहीं है।

Answer 2

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

unsigned int volatile lock_var = 0; 
#define ACQUIRE_LOCK() {                   
        do {                  
         while(lock_var == 1) {            
          _mm_pause;              
         }                 
        } while(__sync_val_compare_and_swap(&lock_var, 0, 1) == 1);    
       } 
#define RELEASE_LOCK() lock_var = 0 
// 

इंटेल द्वारा प्रोसेसर के लिए _mm_pause की सिफारिश की जाती है, इसलिए लॉक को अपडेट करने का समय होता है।

आपका धागा केवल लॉक प्राप्त करते समय लूप के दौरान बाहर निकल जाएगा और फिर महत्वपूर्ण अनुभाग दर्ज करेगा।

यदि आप __sync_val_compare_and_swap के लिए प्रलेखन को देखते हैं तो आपको पता चलेगा कि यह xchgcmp निर्देश के आधार पर है और इस निर्देश के दौरान बस को लॉक करने के लिए उत्पन्न असेंबली में इसके ऊपर शब्द लॉक होगा। यह guarentees एक परमाणु पढ़ने लिखने में संशोधन।