"गैर अवरुद्ध" संगामिति क्या है और यह कैसे सामान्य संगामिति से अलग है?

Question

1. "गैर अवरुद्ध" संगामिति क्या है और यह कैसे सामान्य संगामिति धागे का उपयोग करने से अलग है? हम उन परिदृश्यों में गैर-अवरुद्ध सहमति का उपयोग क्यों नहीं करते हैं जहां समेकन की आवश्यकता होती है? गैर-अवरुद्ध समरूपता का उपयोग करने के लिए उपर है?
2. मैंने सुना है कि गैर अवरुद्ध संगामिति जावा में उपलब्ध है। क्या कोई विशेष परिदृश्य है जहां हमें इस सुविधा का उपयोग करना चाहिए?
3. वहाँ एक अंतर या एक संग्रह के साथ इन विधियों में से एक का उपयोग करने के लाभ है? ट्रेड-ऑफ क्या हैं? Q3 के लिए

उदाहरण:

class List 
{ 
    private final ArrayList<String> list = new ArrayList<String>(); 

    void add(String newValue) 
    { 
     synchronized (list) 
     { 
      list.add(newValue); 
     } 
    } 
} 

बनाम

private final ArrayList<String> list = Collections.synchronizedList(); 

सवालों को देखने के एक सीखने/समझ बिंदु से अधिक कर रहे हैं। ध्यान के लिए धन्यवाद।

Answer 1

गैर-अवरोधन Concurrency और क्या है यह अलग है।

औपचारिक:

कंप्यूटर विज्ञान में, गैर-अवरुद्ध तुल्यकालन सुनिश्चित करता है कि धागे साझा किए गए संसाधन के लिए प्रतिस्पर्धा कर नहीं है उनके निष्पादन को अनिश्चित काल के पारस्परिक अपवर्जन द्वारा स्थगित कर दिया है। गैर-अवरुद्ध एल्गोरिदम पर लॉक-फ्री है, तो सिस्टम-व्यापी प्रगति की गारंटी है; अगर गारंटीकृत प्रति-थ्रेड प्रगति भी है तो प्रतीक्षा करें। (विकिपीडिया)

अनौपचारिक: गैर अवरुद्ध बनाम अवरुद्ध का सबसे लाभप्रद सुविधा की है कि, धागे निलंबित किया जाना है/ओएस द्वारा जागना नहीं है। इस तरह के ओवरहेड कुछ 10ms तक 1ms तक हो सकते हैं, इसलिए इसे हटाने का एक बड़ा प्रदर्शन लाभ हो सकता है। जावा में, इसका मतलब यह भी है कि आप गैर-निष्पक्ष लॉकिंग का उपयोग करना चुन सकते हैं, जिसमें निष्पक्ष-लॉकिंग की तुलना में अधिक सिस्टम थ्रूपुट हो सकता है।

मैंने सुना है कि यह जावा में उपलब्ध है। क्या कोई विशेष परिदृश्य हैं, हमें इस सुविधा का उपयोग करना चाहिए

हाँ, जावा 5 से। असल में, जावा में आपको मूल रूप से java.util.concurrent के साथ अपनी जरूरतों को पूरा करने की कोशिश करनी चाहिए (जो गैर-अवरुद्ध समरूपता का उपयोग करने के लिए होता है, लेकिन आपको ज्यादातर मामलों में स्पष्ट रूप से चिंता करने की आवश्यकता नहीं है)। केवल तभी यदि आपके पास कोई अन्य विकल्प नहीं है, तो आपको सिंक्रनाइज़ रैपर (.synchronizedList() आदि) या मैन्युअल synchronize कीवर्ड का उपयोग करना चाहिए। इस तरह, आप अधिक समय तक अधिक रखरखाव, बेहतर प्रदर्शन करने वाले ऐप्स के साथ समाप्त होते हैं।

गैर-अवरुद्ध समेकन विशेष रूप से फायदेमंद है जब बहुत अधिक विवाद होता है। जब आप को अवरुद्ध करने की आवश्यकता होती है तो आप इसका उपयोग नहीं कर सकते (निष्पक्ष-लॉकिंग, ईवेंट-संचालित सामान, अधिकतम लंबाई आदि के साथ कतार), लेकिन यदि आपको इसकी आवश्यकता नहीं है, तो गैर-अवरुद्ध समरूपता अधिकांश स्थितियों में बेहतर प्रदर्शन करती है।

वहाँ एक संग्रह के लिए इन तरीकों में से एक का उपयोग कर का अंतर/लाभ है। व्यापार बंद

दोनों का एक ही व्यवहार है (बाइट कोड बराबर होना चाहिए)। लेकिन मैं Collections.synchronized का उपयोग करने का सुझाव देता हूं क्योंकि यह छोटा = छोटा कमरा पेंच करने के लिए है!

Answer 2

1) गैर-अवरुद्ध सिंक्रनाइज़ेशन का अर्थ है कि deadlocks का जोखिम हटा दिया गया है। कोई भी थ्रेड "हमेशा के लिए" किसी अन्य थ्रेड द्वारा लॉक प्राप्त करने के लिए इंतजार नहीं करेगा।

2) जावा में गैर-अवरुद्ध तुल्यकालन algorithms पर अधिक।

Answer 3

1. विकिपीडिया किसी भी कंप्यूटर विज्ञान छात्र के लिए एक महान संसाधन है। गैर-अवरुद्ध सिंक्रनाइज़ेशन पर एक आलेख यहां दिया गया है - http://en.wikipedia.org/wiki/Non-blocking_synchronization

2. गैर-अवरुद्ध सिंक्रनाइज़ेशन किसी भी भाषा में उपलब्ध है, इस प्रकार प्रोग्रामर अपने बहु-थ्रेडेड एप्लिकेशन को परिभाषित करता है।

3. आप केवल ताला लगा का उपयोग करना चाहिए (अर्थात सिंक्रनाइज़ (सूची)) जब समय यह ताला प्राप्त करने के लिए ले जाता है के कारण आवश्यक। जावा में, वेक्टर एक थ्रेड सुरक्षित डेटा संरचना है जो जावा के ऐरेलिस्ट के समान ही है।

Answer 4

1) क्या है गैर अवरुद्ध कन्करेंसी और यह किस प्रकार भिन्न है।

एक कार्य (थ्रेड) गैर-अवरुद्ध होता है जब यह कार्य समाप्त होने तक अन्य कार्यों (धागे) का इंतजार नहीं करता है।

2) मैंने सुना है कि यह जावा में उपलब्ध है। क्या कोई विशेष परिदृश्य है जो हमें इस सुविधा का उपयोग करना चाहिए

जावा अपने मल्टीथ्रेडिंग पर समर्थन करता है। आप कई कार्यों को एक साथ चलाने के लिए इसका लाभ उठा सकते हैं। जब अच्छी तरह से लिखा और कार्यान्वित किया जाता है, तो यह कई लॉजिकल सीपीयू वाले मशीन पर चलते समय प्रोग्राम को तेज़ी से बढ़ा सकता है। शुरू करने के लिए, java.lang.Runnable और java.lang.Thread निम्न स्तर की समवर्ती कार्यान्वयन के रूप में हैं। फिर java.util.concurrent एपीआई के स्वाद में उच्च स्तरीय समरूपता है।

3) क्या संग्रह के लिए इन तरीकों में से किसी एक का उपयोग करने का कोई अंतर/लाभ है।क्या व्यापार नापसंद

हैं मैं Collections#synchronizedList() का प्रयोग करेंगे, न केवल क्योंकि एक Map एक List नहीं है कि और अधिक मजबूत और सुविधाजनक है, लेकिन यह भी है क्योंकि। एपीआई पहले से ही सुविधा प्रदान करता है जब घर बढ़ने की कोशिश करने की जरूरत नहीं है।

---

उस ने कहा, Sun tutorial about Concurrency है। मैं आपको इसके माध्यम से प्राप्त करने की सलाह देता हूं।

Answer 5

1] है क्या गैर अवरुद्ध कन्करेंसी और कि यह कैसे अलग है।

दूसरों के रूप में उल्लेख किया है, गैर अवरुद्ध गतिरोध से मुक्त कह (जिसका अर्थ है कि हम एक शर्त है जहाँ प्रगति पूरी तरह से रुकती है, जबकि धागे ब्लॉक किए गए हैं नहीं होना चाहिए, उपयोग करने के लिए प्रतीक्षा में) का एक तरीका है।

'concurrency' का अर्थ क्या है कि एक ही समय में एक साथ कई कंप्यूटेशंस हो रहे हैं (समवर्ती रूप से)।

2] मैंने सुना है कि यह जावा में उपलब्ध है। हम इस सुविधा

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

3] वहाँ एक संग्रह के लिए इन तरीकों में से एक का उपयोग कर का अंतर/लाभ है। व्यापार नापसंद

क्या कर रहे हैं।

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

एक सिंक्रनाइज़लिस्ट (या सिंक्रनाइज़मैप) ऑब्जेक्ट केवल यह सुनिश्चित करता है कि व्यक्तिगत संचालन थ्रेड-सुरक्षित हैं। इसका मतलब है कि दो आवेषण एक साथ नहीं होंगे।

for(int i=0; i < 4; i++){ 
    list.add(Integer.toString(i)); 
} 

तो उपयोग में सूची एक synchronizedList था और इस पाश दो अलग धागे पर मार डाला गया था, तो हम साथ खत्म हो सकता है {0,0,1,2,1,3,2: निम्नलिखित पाश पर विचार करें , 3} हमारी सूची में, या कुछ अन्य क्रमपरिवर्तन।

क्यों? खैर, हमें गारंटी है कि थ्रेड 1 उस क्रम में 0-3 जोड़ देगा और हमें थ्रेड 2 की गारंटी दी जाएगी, हालांकि हमें इस बात की कोई गारंटी नहीं है कि वे कैसे हस्तक्षेप करेंगे।

अगर, हालांकि, हम एक तुल्यकालन (सूची) ब्लॉक में इस सूची लिपटे:

synchronized(list){ 
    for(int i=0; i < 4; i++){ 
     list.add(Integer.toString(i)); 
    } 
} 

हम गारंटी है कि धागा 1 और धागा 2 से आवेषण बिछा नहीं होगा, लेकिन वे एक ही बार में सब हो जाएगा । हमारी सूची में {0,1,2,3,0,1,2,3} होगा। दूसरा धागा ब्लॉक पर, सूची पर प्रतीक्षा करेगा, जब तक कि पहला धागा पूरा न हो जाए। हमारे पास कोई गारंटी नहीं है कि कौन सा धागा पहले होगा, लेकिन हमें गारंटी है कि यह दूसरे शुरू होने से पहले खत्म हो जाएगा।

तो, कुछ व्यापार गत हैं:

• एक syncrhonizedList के साथ, आप स्पष्ट रूप से एक सिंक्रनाइज़ ब्लॉक का उपयोग किए बिना सम्मिलित कर सकते हैं।
• एक syncrhonizedList आप सुरक्षा के एक झूठी भावना दे सकता है, जब से तुम भोलेपन से एक धागे पर विश्वास करते हैं लगातार opertaions होने की परमाणु, जब केवल व्यक्तिगत संचालन परमाणु हैं
• एक syncrhonized (सूची) ब्लॉक चाहिए का उपयोग करना देखभाल के साथ किया जाना चाहिए, क्योंकि हम डेडलॉक बनाने की स्थिति में हैं (नीचे और अधिक)।

हम एक गतिरोध जब दो (या अधिक) धागे एक दूसरे के पास मौजूद संसाधनों के उपसमूह के लिए इंतजार कर रहे हैं बना सकते हैं। यदि, उदाहरण के लिए, आपके पास दो सूचियां थीं: उपयोगकर्ता सूची और मूवीलिस्ट।

यदि थ्रेड 1 पहले उपयोगकर्ता को लॉक प्राप्त करता है, तो फिल्म सूची, लेकिन थ्रेड दो इन चरणों को रिवर्स में निष्पादित करता है (उपयोगकर्ता सूची से पहले फिल्म सूची में लॉक प्राप्त करता है), तो हमने डेडलॉक के लिए स्वयं को खोला है। घटनाओं के निम्नलिखित पाठ्यक्रम पर विचार करें:

1. थ्रेड 1 उपयोगकर्ता सूची
2. थ्रेड के लिए लॉक हो जाता है 2 ताला movieList
3. थ्रेड के लिए 1 की कोशिश करता movieList को ताला पाने के लिए, हो जाता है थ्रेड 2 पर इंतजार कर रहा है
4. थ्रेड जारी करने के लिए 2 उपयोगकर्ता सूची को लॉक करने का प्रयास करता है,

दोनों धागे दूसरे की प्रतीक्षा कर रहे हैं और न ही आगे बढ़ सकते हैं। यह एक अवरुद्ध परिदृश्य है, और चूंकि न तो इसके संसाधन को छोड़ देगा, हम मरे हुए हैं।

Answer 6

क्या है गैर अवरुद्ध संगामिति और यह कैसे की तुलना में सामान्य कन्करेंसी धागे का उपयोग कर अलग है।

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

हम उन परिदृश्यों में "गैर-अवरुद्ध" सहमति का उपयोग क्यों नहीं करते हैं जहां सहमति की आवश्यकता होती है।

हम करते हैं। मैं आपको थोड़ा सा दिखाऊंगा। लेकिन यह सच है कि प्रत्येक समवर्ती समस्या के लिए हमेशा कुशल गैर-अवरुद्ध एल्गोरिदम नहीं होते हैं।

हैं वहाँ "गैर अवरुद्ध"

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

मैंने सुना है कि यह जावा में उपलब्ध है।

बिल्कुल। शुरुआत के लिए, java.util.concurrent.atomic में सभी कक्षाएं साझा चर के लॉक-फ्री रखरखाव प्रदान करती हैं। इसके अलावा, java.util.concurrent के सभी वर्ग जिनके नाम ConcurrentLinked या ConcurrentSkipList से शुरू होते हैं, सूचियों, मानचित्रों और सेटों के लॉक-मुक्त कार्यान्वयन प्रदान करते हैं।

क्या कोई विशेष परिदृश्य है जो हमें इस सुविधा का उपयोग करना चाहिए।

आप सभी मामलों में जहां आप अन्यथा (पूर्व JDK 1.5) Collections.synchronizedlist, का प्रयोग करेंगे के रूप में वे सबसे परिस्थितियों में बेहतर प्रदर्शन प्रदान में ताला मुक्त कतार और Deque का उपयोग करना चाहते हैं। यानी, आप उनका उपयोग करेंगे जब भी एक से अधिक धागे संग्रह को संशोधित रूप से संशोधित कर रहे हों, या जब एक धागा संग्रह को संशोधित कर रहा है और अन्य धागे इसे पढ़ने का प्रयास कर रहे हैं। ध्यान दें कि बहुत लोकप्रिय ConcurrentHashMap वास्तव में आंतरिक रूप से ताले का उपयोग करता है, लेकिन यह ConcurrentSkipListMap से अधिक लोकप्रिय है क्योंकि मुझे लगता है कि यह अधिकांश परिदृश्यों में बेहतर प्रदर्शन प्रदान करता है। हालांकि, मुझे लगता है कि जावा 8 में ConcurrentHashMap का लॉक-फ्री कार्यान्वयन शामिल होगा।

क्या संग्रह के लिए इन तरीकों में से किसी एक का उपयोग करने का कोई अंतर/लाभ है। व्यापार बंद

ठीक है, इस संक्षिप्त उदाहरण में, वे बिल्कुल वही हैं। नोट, हालांकि, जब आपके समवर्ती पाठक और लेखकों के पास होते हैं, तो आपको पठन और साथ ही लिखने को सिंक्रनाइज़ करना होगा, और संग्रह। सिंक्रनाइज़लिस्ट() ऐसा करता है। आप वैकल्पिक रूप से लॉक-फ्री ConcurrentLinkedQueue को एक विकल्प के रूप में आजमा सकते हैं। यह आपको कुछ परिदृश्यों में बेहतर प्रदर्शन दे सकता है।

जनरल नोट

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

Answer 7

1: "गैर अवरुद्ध" संगामिति क्या है और यह कैसे सामान्य संगामिति धागे का उपयोग करने से अलग है? हम उन परिदृश्यों में गैर-अवरुद्ध सहमति का उपयोग क्यों नहीं करते हैं जहां समेकन की आवश्यकता होती है? गैर-अवरुद्ध समरूपता का उपयोग करने के लिए उपर है?

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

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

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

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

2: मैंने सुना है कि जावा में गैर-अवरुद्ध समरूपता उपलब्ध है। क्या कोई विशेष परिदृश्य है जहां हमें इस सुविधा का उपयोग करना चाहिए?

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

3: क्या संग्रह के साथ इन तरीकों में से किसी एक का उपयोग करने में कोई अंतर या लाभ है? ट्रेड-ऑफ क्या हैं?

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

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

वास्तव में यह वास्तव में गड़बड़ करना बहुत मुश्किल है, जो इसे डीबग करना बहुत मुश्किल है, इसलिए यदि आपको ऐसा करने की ज़रूरत नहीं है (जिसे मैंने केवल कुछ परिदृश्य पाए हैं जहां आप कभी भी करेंगे; और मेरे लिए वे बहुत संदिग्ध थे और मैं इसे नहीं करना चाहूंगा) ऐसा मत करो। मानक सामान का उपयोग करें और हर कोई खुश होगा!

चर्चा/कोड

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

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

कार्यान्वयन है कि मैं इस प्रयोग कैस संचालन और चर के परमाणु परिवार के लिए किया है। इस मूल कोड ने इस उपयोग मामले में मेरे लिए किसी भी त्रुटि को लॉक या उठाया नहीं है (यादृच्छिक नमूना इनपुट और उच्च माध्यमिक अनुवाद प्रणाली से ऑफ़लाइन परीक्षण के लिए आउटपुट)। यह मूल रूप से इस तरह काम करता है:

आपके पास कुछ वस्तु है जो धागे के बीच साझा की जाती है, और इसे या तो एटमिकXXक्स या परमाणु संदर्भ के रूप में घोषित किया जाता है (अधिकांश गैर-तुच्छ उपयोग के मामलों के लिए आप परमाणु संदर्भ संस्करण के साथ भाग लेंगे)।

जब दिए गए मूल्य/ऑब्जेक्ट का संदर्भ दिया है, आप इसे परमाणु आवरण से पुनः प्राप्त, यह आप एक स्थानीय प्रति जिस पर आप कुछ संशोधन प्रदर्शन हो जाता है। यहाँ से आप अपने धागे से इस परमाणु स्थापित करने के लिए अगर यह विफल रहता है यह गलत रिटर्न के रूप में ताला लगा के लिए विरोध प्रयास करने के लिए थोड़ी देर के पाश की शर्त के रूप में एक compareAndSwap का उपयोग करें। यह तब तक सक्रिय होगा जब तक यह काम नहीं करता है (इस लूप में कोड बहुत ही कुशल और सरल होना चाहिए)।

आप सीएएस ऑपरेशंस को देख सकते हैं कि वे कैसे काम करते हैं, यह मूल रूप से एक निर्देश के रूप में लागू किया जाना चाहिए ताकि यह देखने के लिए अंत में तुलना की जा सके कि मूल्य क्या है जिसे आपने इसे सेट करने का प्रयास किया है।

compareAndSwap में विफल रहता है, तो आप अपने वस्तु फिर से परमाणु आवरण से, प्राप्त किसी भी संशोधन को फिर से, और फिर तुलना और स्वैप फिर से जब तक यह काम करता है की कोशिश करो। कोई विशेष ताला तुम सिर्फ वस्तु स्मृति में वापस स्थापित करने के लिए कोशिश कर रहे हैं और अगर यह विफल रहता है तो आप सिर्फ फिर से जब भी आपके धागा फिर से नियंत्रण हो जाता है की कोशिश भी है।

/* field declaration*/ 
//Note that I have an initialization block which ensures that the object in this 
//reference is never null, this was required to remove null checks and ensure the CAS 
//loop was efficient enough to improve performance in my use case 
private AtomicReference<List<SampleRuleMessage>> specialSamplingRulesAtomic = new AtomicReference<List<SampleRuleMessage>>(); 


/*start of interesting code section*/ 

    List<SampleRuleMessage> list = specialSamplingRulesAtomic.get(); 
    list.add(message); 
    while(!specialSamplingRulesAtomic.compareAndSet(specialSamplingRulesAtomic.get(), list)){ 
     list = specialSamplingRulesAtomic.get(); 
     list.add(message); 
    }; 
/* end of interesting code section*/ 

Answer 8

गैर अवरुद्ध तुल्यकालन ही एक अवरुद्ध तुल्यकालन, दोनों तुल्यकालन की तरह कर रहे हैं, केवल अंतर यह है कि गैर-अवरुद्ध तुल्यकालन:

इस के लिए कोड एक सूची के साथ एक सरल मामले के लिए नीचे है कुल मिलाकर तेजी से है।

शुरुआत के लिए आप केवल तुल्यकालन उपयोग करने के लिए जब एक से अधिक थ्रेड रैम में एक ही संसाधन का उपयोग करना चाहते हैं। जब डिस्क पर चीजों का उपयोग करने की कोशिश कर आप तुल्यकालन उपयोग नहीं कर सकते, या बेहतर कहा, आप डिस्क पर ताले उपयोग करने के लिए की जरूरत है।

जिसके अनुसार, आप कैसे सिंक्रनाइज़ कर सकते हैं अगर कोई धागा कभी ब्लॉक?

जवाब आशावादी ताला है। यह विचार कम से कम 20 वर्षों तक अस्तित्व में है। शायद और।

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

लिस्प में आप राज्य को साझा किया है सकते हैं, लेकिन यह मुश्किल हो जाता है। तो अधिकांश कार्यक्रम समानांतर में चल सकते हैं और सिंक्रनाइज़ेशन के बारे में कभी चिंता नहीं करते हैं।

आशावादी लॉकिंग का विचार यह है कि सभी धागे स्वेच्छा से मूल्यवान साझा किए गए संशोधित होते हैं, लेकिन उनके पास मूल्यों को संशोधित करने के लिए एक स्थानीय क्षेत्र होता है, और केवल एक निर्देश के साथ, अंत में संशोधन को लागू करता है, सीएएस का उपयोग करके। कैस की तुलना करें और स्वैप के लिए, यह सिर्फ एक सीपीयू चक्र में करता है, और यह कम से कम 20 साल के लिए सीपीयू में लागू किया गया है।

एक क्या कैस है के उत्कृष्ट स्पष्टीकरण: https://www.cs.umd.edu/class/fall2010/cmsc433/lectures/nonBlocking.pdf

तो अगर वहाँ संशोधन में एक संघर्ष है, यह केवल लेखकों में से एक को प्रभावित करेगा, बाकी इसके साथ किया जाएगा।

इसके अलावा, यदि कोई विवाद नहीं है, तो गैर-अवरुद्ध एल्गोरिदम उनके अवरुद्ध समकक्षों की तुलना में बहुत तेज़ प्रदर्शन करते हैं।

पर ट्यूटोरियल गैर अवरुद्ध कोड उदाहरण के साथ जावा में एल्गोरिदम आप वास्तविक जीवन में उपयोग कर सकते हैं: http://tutorials.jenkov.com/java-concurrency/non-blocking-algorithms.html