2012-09-10 16 views
27

मैंने खोजा और पाया कि अपरिवर्तनीय थ्रेड सुरक्षित है जबकि mutable नहीं है। यह ठीक है। लेकिन मुझे भ्रामक नोट्स, ब्लॉग, थ्रेड सुरक्षा के बारे में परमाणु बनाम गैर-परमाणु के बारे में उत्तर मिल गया, कृपया उत्तर के लिए एक स्पष्टीकरण दें।थ्रेडसेफ परमाणु या गैर परमाणु कौन सा है?

मान लीजिए एक परमाणु स्ट्रिंग संपत्ति "नाम" कहा जाता है, और यदि आप धागा एक से [self setName:@"A"] फोन, धागा बी से [self setName:@"B"] कहते हैं, और धागा सी से [self name] कहते हैं, तो अलग धागे पर सभी ऑपरेशन क्रमानुसार प्रदर्शन किया जाएगा जो साधन यदि एक धागा सेटटर या गेटर निष्पादित कर रहा है, तो अन्य धागे इंतजार करेंगे। इससे संपत्ति "नाम" सुरक्षित/लिखना सुरक्षित हो जाता है लेकिन यदि कोई अन्य थ्रेड डी [name release] एक साथ कॉल करता है तो यह ऑपरेशन एक क्रैश उत्पन्न कर सकता है क्योंकि यहां कोई सेटटर/गेटर कॉल शामिल नहीं है। जिसका अर्थ है कि ऑब्जेक्ट को सुरक्षित/लिखना सुरक्षित है (एटीओएमआईसी) लेकिन थ्रेड सुरक्षित नहीं है क्योंकि एक और धागे ऑब्जेक्ट को किसी भी प्रकार के संदेश भेज सकते हैं।

यदि संपत्ति "नाम" nonatomic था, तो उपरोक्त उदाहरण में सभी धागे - ए, बी, सी और डी किसी भी अप्रत्याशित परिणाम के साथ-साथ निष्पादित निष्पादित करेंगे। परमाणु के मामले में, ए, बी या सी में से कोई भी पहले निष्पादित करेगा लेकिन डी अभी भी समानांतर में निष्पादित हो सकता है। इस पर

तुम्हारा टिप्पणी हमें मदद मिलेगी ....

और मेरे सवाल यह है कि, "जो कोको में धागा सुरक्षित, परमाणु या गैर परमाणु है?"

+2

http://www.google.com.ph/search?क्यू = उद्देश्य + सी + परमाणु + बनाम + nonatomic और aq = 0 और oq = उद्देश्य + सी + परमाणु + बनाम + गैर और sugexp = क्रोम, mod = 10 और स्रोत आईडी = क्रोम और यानी = यूटीएफ -8 – janusbalatbat

उत्तर

61

ObjC गुण के लिए - न तो धागा सुरक्षित हैं।

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

प्रतिरोधी थ्रेडिंग त्रुटियों के लिए 'गुणवत्ता' नहीं है - यह वास्तविक थ्रेडिंग त्रुटियों को मुखौटा करने में मदद करता है और उन्हें पुन: पेश करने और पहचानने में अधिक कठिन बना देता है।

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


प्रश्न विस्तारित: धागा ए, कॉल:

मान लीजिए एक परमाणु स्ट्रिंग संपत्ति "नाम" कहा जाता है, और यदि आप [@ 'ए' आत्म setName] फोन [स्वयं सेटनाम: @ "बी"] थ्रेड बी से, और थ्रेड सी से [स्वयं नाम] कॉल करें, फिर विभिन्न धागे पर सभी ऑपरेशन क्रमशः किया जाएगा जिसका अर्थ है कि अगर एक थ्रेड सेटटर या गेटर निष्पादित कर रहा है, तो अन्य थ्रेड इंतजार करेंगे।

यदि सभी धागे एक ही समय में संपत्ति को पढ़ने और/या लिखने की कोशिश करते हैं, तो केवल एक थ्रेड में एक समय तक पहुंच होगी और अन्य को अवरुद्ध कर दिया जाएगा यदि संपत्ति परमाणु थे। अगर संपत्ति nonatomic थे, तो वे सभी एक ही "समय" पर परिवर्तनीय को पढ़ने और लिखने के लिए अनजान होगा।

यदि कोई अन्य थ्रेड डी कॉल [नाम रिलीज] एक साथ होता है तो यह ऑपरेशन क्रैश उत्पन्न कर सकता है क्योंकि यहां कोई सेटटर/गेटर कॉल शामिल नहीं है।

सही।

जिसका अर्थ है कि कोई ऑब्जेक्ट पढ़ा/लिखना सुरक्षित है (एटीओएमआईसी) लेकिन थ्रेड सुरक्षित नहीं है क्योंकि एक और धागे ऑब्जेक्ट को किसी भी प्रकार के संदेश भेज सकते हैं।

ठीक है, इसके लिए वास्तव में बहुत कुछ है। सामान्य उदाहरण है:

@interface MONPerson : NSObject 

    @property (copy) NSString * firstName; 
    @property (copy) NSString * lastName; 

    - (NSString *)fullName; 

    @end 

परमाणु, या nonatomic, आप अगर एक धागा कि उदाहरण से पढ़ रही है और एक अन्य इसे करने के लिए लिख रहे हैं (उदाहरण के लिए ताला) एक तुल्यकालन तंत्र की आवश्यकता होगी। आप एक MONPerson के firstName के साथ खत्म हो सकता है और एक अन्य lastName है - पहले गेटर द्वारा दिया गया मान भी आप के लिए दिया जाता है वस्तु बदल गया हो, या ऐसा कर सकते हैं:

थ्रेड एक:

p.firstName = @"Rob"; 

थ्रेड बी :

p.firstName = @"Robert"; 

थ्रेड एक:

label.string = p.firstName; // << uh, oh -- will be Robert 

यदि संपत्ति "नाम" nonatomic था, तो उपर्युक्त उदाहरण में सभी धागे - ए, बी, सी और डी किसी भी अप्रत्याशित परिणाम के साथ-साथ निष्पादित निष्पादित करेंगे।

दाएं - प्रारंभिक लक्षण संदर्भ गणना असंतुलन (रिसाव, ओवर-रिलीज) हो सकते हैं।

परमाणु के मामले में, ए, बी या सी में से कोई भी पहले निष्पादित करेगा लेकिन डी अभी भी समानांतर में निष्पादित हो सकता है। कृपया इस पर टिप्पणी करें ....

सही।लेकिन यदि आप ऊपर दिए गए उदाहरण को देखते हैं - अकेले परमाणु लॉक के लिए शायद ही कोई उपयुक्त प्रतिस्थापन है। यह इस के बजाय की तरह लग रहे करने के लिए होगा:

थ्रेड एक:

[p lock]; // << wait for it… … … … 
// Thread B now cannot access p 
p.firstName = @"Rob"; 
NSString fullName = p.fullName; 
[p unlock]; 
// Thread B can now access p 
label.string = fullName; 

थ्रेड बी:

[p lock]; // << wait for it… … … … 
// Thread A now cannot access p 
… 
[p unlock]; 

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

+0

इतने सारे विवरण में वर्णन करने के लिए धन्यवाद, यह निश्चित रूप से मुझे और अन्य लोगों को कोको भविष्य में मदद करेगा :) –

10

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

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

+0

धन्यवाद आपके उत्तर के लिए जेरिक। तो दो में से कोई भी, परमाणु और गैर परमाणु थ्रेड सुरक्षित हैं? –

+0

नहीं, यह मेरे उत्तर की तरह है। यह केवल यह सुनिश्चित करता है कि गेटर मूल्यों को वापस लाता है जो बहु-थ्रेडेड वातावरण में समझ में आता है। – Asciiom

+0

पूरा मूल्य प्राप्त करने का क्या अर्थ होगा? मैं किस तरह की त्रुटियों को देखूँगा? – powerj1984

-1

आपको लॉकिंग तंत्र को लागू करने पर विचार करना चाहिए ताकि आपको अपने ऐप में डेडलॉक न मिले। यदि आप कोर डेटा को कार्यान्वित कर रहे हैं तो आपको आईओएस थ्रेड सुरक्षा पर पढ़ना चाहिए।

देखें।

http://developer.apple.com/library/iOS/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

http://developer.apple.com/library/iOS/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html%23//apple_ref/doc/uid/10000057i-CH8-SW1

+1

आपके उत्तर के लिए धन्यवाद आईरिस। मुझे लॉकिंग और @ सिंक्रनाइज़ करने के बारे में पता है, लेकिन मैं सिर्फ यह पुष्टि करना चाहता था कि कौन सा धागा सुरक्षित है और क्यों? –

+0

सही ढंग से लागू होने पर परमाणु थ्रेड सुरक्षित है, गैर परमाणु थ्रेड सुरक्षित नहीं है और इस प्रकार तेज़ है लेकिन थ्रेड के साथ उपयोग नहीं किया जाता है। – StackRunner

+0

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

7

परमाणु निम्नलिखित थ्रेड को सुरक्षित बनाता है।

self.myProperty = value; 

या

id value = self.myProperty 

यह निम्नलिखित धागा सुरक्षित नहीं है

[myPorperty addObject:value]; 

परमाणु इसे सुरक्षित थ्रेड सेट या एक संपत्ति प्राप्त करने के लिए करता है, लेकिन यह किसी भी बुला नहीं है उस संपत्ति के तरीके स्वयं धागे सुरक्षित हैं।

सेटिंग या मूल्य प्राप्त करने से एक से अधिक CPU निर्देश ले सकते हैं और इसका मतलब है कि सेटिंग या प्राप्त करना आधे रास्ते में बाधित हो सकता है और दूसरा धागा पिछले धागे की प्रगति को अमान्य बनाने या प्राप्त करने में कुछ कर सकता है।

परमाणु कहते हैं कि सेट को सेट करें या एक तरह से मूल्य प्राप्त करें ताकि ऐसा होता है जैसे यह एक अविभाज्य निर्देश में हुआ और इसलिए कोई अन्य धागा आधे रास्ते में कदम उठा सकता है और चीज़ों को पेंच कर सकता है।

अपरिवर्तनीय वस्तु थ्रेड सुरक्षित सरल है क्योंकि आप उन्हें बदल नहीं सकते हैं, क्योंकि आप एक अपरिवर्तनीय वस्तु से किसी अन्य संपत्ति को बदल सकते हैं ताकि जब तक आप इसे परमाणु नहीं बनाते तब तक हिस्सा सुरक्षित नहीं होगा।

1

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

-6

गैर परमाणु धागा सुरक्षित है। गुरुत्वाकर्षण चर का मूल्य मिलता है।

0

1) दोनों गैर थ्रेड सुरक्षित हैं। 2) परमाणु केवल एक पठन-लेखन सुरक्षित है। 3) हालांकि यदि आप थ्रेड को सुरक्षित बनाना चाहते हैं तो आपको कुछ लॉकिंग तंत्र को म्यूटेक्स लॉक, स्पिन लॉक जैसे थ्रेड पर लागू करने की आवश्यकता है। और पढ़ें ... https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html

संबंधित मुद्दे