"थ्रेड-सुरक्षित" कोड का क्या अर्थ है?

क्या इसका मतलब यह है कि दो धागे अंतर्निहित डेटा को एक साथ नहीं बदल सकते हैं? या इसका मतलब यह है कि दिया गया कोड सेगमेंट पूर्वानुमानित परिणामों के साथ चलाएगा जब एक से अधिक धागे इसे चला रहे हों?

0
इस सवाल को थोड़ा विचित्र रूप से phrased है। मैं वास्तव में महत्वपूर्ण परिणामों के संदर्भ में "अनुमानित" ("अप्रत्याशित" नहीं) परिणाम कहता। निश्चित रूप से कौन सा धागा तेजी से चलता है या जल्दी खत्म होता है, अप्रत्याशित/गैर-निर्धारिती (या नहीं, यदि आप कुछ अतिरिक्त लॉकिंग करते हैं) हो सकता है, लेकिन सुरक्षित कोड को कॉल करने वाले कोड को "पदार्थ" के किसी भी प्रभाव को अप्रत्याशित नहीं किया जाना चाहिए।
जोड़ा लेखक Jon Coombs, स्रोत
इस मामले के बारे में यहां एक दिलचस्प चर्चा देखी गई: blogs.msdn.com/ericlippert/archive/2009/10/19/…
जोड़ा लेखक Sebastian, स्रोत

15 उत्तर

दृढ़ता के साथ धागा सुरक्षा भ्रमित मत करो। थ्रेड-सुरक्षित कोड भी गैर-निर्धारक हो सकता है। थ्रेडेड कोड के साथ समस्याओं को डीबग करने की कठिनाई को देखते हुए, यह शायद सामान्य मामला है। :-)

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

0
जोड़ा

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

0
जोड़ा

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

मुझे अभ्यास में जावा Concurrency द्वारा दी गई परिभाषा पसंद है:

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

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

योगदान उदाहरण

कल्पना करें कि आप एक काउंटर लागू करते हैं। आप कह सकते हैं कि यह सही तरीके से व्यवहार करता है यदि:

  • counter.next() never returns a value that has already been returned before (we assume no overflow etc. for simplicity)
  • all values from 0 to the current value have been returned at some stage (no value is skipped)

एक धागा सुरक्षित काउंटर उन नियमों के अनुसार व्यवहार करेगा चाहे इस पर कितने धागे इसे समेकित रूप से एक्सेस करते हैं (जो आम तौर पर निष्पक्ष कार्यान्वयन का मामला नहीं होगा)।

नोट: प्रोग्रामर पर क्रॉस-पोस्ट

0
जोड़ा

मैं अन्य अच्छे उत्तरों के शीर्ष पर कुछ और जानकारी जोड़ना चाहता हूं।

Thread safety implies multiple threads can write/read data in same object without memory inconsistency errors. In highly multi threaded program, a thread safe program does not cause side effects to shared data.

अधिक जानकारी के लिए इस एसई प्रश्न पर एक नज़र डालें:

थ्रेडसेफ का क्या अर्थ है?

Thread safe program guarantees memory consistency.

ऑरैक दस्तावेज़ से पृष्ठ उन्नत समवर्ती एपीआई पर:

मेमोरी संगठनात्मक गुण:

Chapter 17 of The Java™ Language Specification defines the happens-before relation on memory operations such as reads and writes of shared variables. The results of a write by one thread are guaranteed to be visible to a read by another thread only if the write operation happens-before the read operation.

सिंक्रनाइज़ और अस्थिर संरचनाएं, साथ ही साथ Thread.start() और Thread.join() विधियां , होता है-पहले संबंध बना सकते हैं।

java.util.concurrent में सभी वर्गों के तरीके और इसके सबपैकेज इन गारंटीओं को उच्च स्तरीय सिंक्रनाइज़ेशन तक बढ़ाते हैं। विशेष रूप से:

  1. किसी ऑब्जेक्ट को किसी समवर्ती संग्रह में रखने से पहले किसी थ्रेड में क्रियाएं किसी अन्य थ्रेड में संग्रह से उस तत्व को एक्सेस या हटाने के बाद होती हैं।
  2. एक निष्पादन शुरू होने से पहले निष्पादक होने पर Runnable को सबमिट करने से पहले किसी थ्रेड में क्रियाएं होती हैं। इसी तरह कॉलबेल के लिए execorService पर सबमिट किया गया।
  3. किसी अन्य थ्रेड में Future.get() के माध्यम से परिणाम की पुनर्प्राप्ति के बाद भविष्य द्वारा किए गए एसिंक्रोनस गणना द्वारा किए गए क्रियाएं।
  4. lock.unlock, Semaphore.release, और countDownLatch.countDown जैसे सफल "अधिग्रहण" के बाद होने वाली कार्रवाइयों से पहले सिंक्रनाइज़र विधियों को "रिलीज़" करने से पहले क्रियाएं विधि जैसे Lock.lock, Semaphore.acquire, Condition.await, और CountDownLatch.await उसी सिंक्रनाइज़र ऑब्जेक्ट पर किसी अन्य थ्रेड में।
  5. प्रत्येक थ्रेड में एक्सचेंजर से पहले क्रियाओं को सफलतापूर्वक एक्सचेंज करने वाले थ्रेड की प्रत्येक जोड़ी के लिए, संबंधित थ्रेड के बाद होने वाले पहले से पहले (कोड> एक्सचेंज() से पहले की कार्रवाइयां होती हैं ( ) एक और धागे में।
  6. कॉल करने से पहले क्रियाएं CyclicBarrier.await और Phaser.awaitAdvance (साथ ही साथ इसके रूप) बाधा कार्रवाई द्वारा किए गए कार्यों से पहले होती हैं, और द्वारा किए गए कार्यों बाधा कार्रवाई होती है-इससे पहले कि अन्य धागे में इसी तरह की प्रतीक्षा से सफल वापसी के बाद की कार्रवाइयां होती हैं।
0
जोड़ा

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

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

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

0
जोड़ा
जावा पृष्ठभूमि से आ रहा है, यह बहुत स्पष्ट है।
जोड़ा लेखक Manee.O.H, स्रोत

मुझे इसकी व्यापकता के लिए प्रैक्टिस में ब्रायन गोएट्ज़ की जावा कंसुरेंसी से परिभाषा पसंद है

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

0
जोड़ा

अन्य उत्तरों को पूरा करने के लिए:

सिंक्रनाइज़ेशन केवल एक चिंता है जब आपकी विधि में कोड दो चीजों में से एक करता है:

  1. कुछ बाहरी संसाधनों के साथ काम करता है जो थ्रेड सुरक्षित नहीं है।
  2. एक सतत वस्तु या कक्षा फ़ील्ड को पढ़ता या बदलता है

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

थ्रेड शेड्यूलिंग को राउंड-रॉबिन होने की गारंटी नहीं है। एक कार्य पूरी तरह से प्राथमिकता के धागे की कीमत पर सीपीयू को हॉग कर सकता है। आप एक विवेक रखने के लिए Thread.yield() का उपयोग कर सकते हैं। थ्रेड की प्राथमिकता को कम करने के लिए आप (जावा में) Thread.setPriority (Thread.NORM_PRIORITY-1) का उपयोग कर सकते हैं

इसके अलावा सावधान रहें:

  • बड़ी "रन-सुरक्षित" संरचनाओं पर लागू होने वाले अनुप्रयोगों पर बड़ी रनटाइम लागत (पहले से ही दूसरों द्वारा निर्दिष्ट)।
  • थ्रेड.sleep (5000) 5 सेकंड के लिए सोना चाहिए। हालांकि, अगर कोई सिस्टम समय बदलता है, तो आप बहुत लंबे समय तक सो सकते हैं या बिलकुल भी नहीं। ओएस जागरूक समय को पूर्ण रूप में रिकॉर्ड करता है, रिश्तेदार नहीं।
0
जोड़ा

एक और जानकारीपूर्ण सवाल यह है कि कोड को थ्रेड सुरक्षित नहीं बनाता है- और जवाब यह है कि चार स्थितियां हैं जो सत्य होनी चाहिए ... निम्नलिखित कोड की कल्पना करें (और यह मशीन भाषा अनुवाद है)

totalRequests = totalRequests + 1
MOV EAX, [totalRequests]  //load memory for tot Requests into register
INC EAX                   //update register
MOV [totalRequests], EAX  //store updated value back to memory
  1. पहली शर्त यह है कि स्मृति स्थान हैं जो एक से अधिक धागे से सुलभ हैं। आम तौर पर, ये स्थान वैश्विक/स्थैतिक चर होते हैं या वैश्विक/स्थैतिक चर से पहुंचने योग्य ढेर मेमोरी हैं। प्रत्येक धागे को फंक्शन/विधि स्कोप्ड स्थानीय चर के लिए अपना स्वयं का ढेर फ्रेम मिलता है, इसलिए ये स्थानीय फ़ंक्शन/विधि चर, ओओटीएच, (जो स्टैक पर हैं) केवल उस थ्रेड से पहुंच योग्य होते हैं जो उस ढेर के मालिक होते हैं।
  2. दूसरी शर्त यह है कि एक संपत्ति है (जिसे अक्सर invariant कहा जाता है), जो कि इन साझा मेमोरी स्थानों से जुड़ा हुआ है, जो प्रोग्राम सही तरीके से कार्य करने के लिए सत्य या वैध होना चाहिए। उपर्युक्त उदाहरण में, संपत्ति यह है कि " कुल रिक्वेस्ट को किसी भी थ्रेड ने वृद्धि विवरण के किसी भी हिस्से को निष्पादित करने की कुल संख्या का सटीक रूप से प्रतिनिधित्व करना होगा "। आमतौर पर, इस परिवर्तनीय संपत्ति को सही होने की आवश्यकता होने से पहले (इस मामले में, कुल रिक्वेस्ट्स को सटीक गणना करना चाहिए) सही होने की आवश्यकता है।
  3. तीसरी स्थिति यह है कि वास्तविक अद्यतन के कुछ हिस्सों के दौरान invariant संपत्ति नहीं रखती है। (प्रसंस्करण के कुछ हिस्सों में यह अस्थायी रूप से अमान्य या गलत है)। इस विशेष मामले में, जब तक अद्यतन मूल्य संग्रहीत किया जाता है, तब तक कुल रिकॉर्ड्स प्राप्त किए जाते हैं, कुल अनुरोध नहीं आविष्कार को संतुष्ट करते हैं।
  4. चौथी और अंतिम स्थिति जो होने वाली दौड़ के लिए होनी चाहिए (और इसलिए कोड के लिए NOT "थ्रेड-सुरक्षित" होना चाहिए) यह है कि एक और थ्रेड होना चाहिए साझा स्मृति जबकि आविष्कार टूट गया है, जिससे असंगत या गलत व्यवहार हो रहा है।
0
जोड़ा
इसमें केवल डेटा दौड़ के रूप में जाना जाता है, और यह निश्चित रूप से महत्वपूर्ण है। फिर भी, अन्य तरीकों से कोड कैसे थ्रेड सुरक्षित नहीं हो सकता है - उदाहरण के लिए खराब लॉकिंग जो डेडलॉक्स का कारण बन सकती है। यहां तक ​​कि जावा थ्रेड में कहीं भी System.exit() को कॉल करने जैसी कुछ सरलता है कि कोड थ्रेड सुरक्षित नहीं है।
जोड़ा लेखक Ingo, स्रोत
खैर, डेडलॉक्स तब तक नहीं हो सकते जब तक कि आप बहु-थ्रेडेड कोर्स नहीं कर रहे हों, लेकिन ऐसा लगता है कि यदि आप एक मशीन पर चल रहे हैं तो नेटवर्क समस्याएं नहीं हो सकती हैं। अन्य समस्याएं एकल-थ्रेडेड भी हो सकती हैं, यदि प्रोग्रामर कोड लिखता है ताकि यह अपडेट को पूरा करने से पहले कोड की महत्वपूर्ण पंक्तियों से बाहर हो जाए, और कुछ अन्य सबराउटिन में चर को संशोधित करता है।
जोड़ा लेखक Charles Bretana, स्रोत
मुझे लगता है कि यह कुछ डिग्री है, यह अर्थशास्त्र है, लेकिन मैं तर्क दूंगा कि खराब लॉकिंग कोड जो डेडलॉक का कारण बन सकता है, कोड को असुरक्षित नहीं बनाता है। सबसे पहले, कोड को पहले स्थान पर लॉक करने की आवश्यकता नहीं है जब तक ऊपर वर्णित रेस स्थिति संभव नहीं है। फिर, यदि आप लॉकिंग कोड को इस तरह से लिखते हैं कि डेडलॉक का कारण बनता है, तो यह थ्रेड-असुरक्षित नहीं है, यह केवल खराब कोड है।
जोड़ा लेखक Charles Bretana, स्रोत
लेकिन ध्यान दें कि सिंगल-थ्रेडेड चलाते समय डेडलॉक नहीं होगा, इसलिए हम में से अधिकांश के लिए यह निश्चित रूप से (नहीं) "थ्रेड-सुरक्षित" के अंतर्ज्ञानी अर्थ के तहत आ जाएगा।
जोड़ा लेखक Jon Coombs, स्रोत

हां और ना।

थ्रेड सुरक्षा केवल यह सुनिश्चित करने से थोड़ा अधिक है कि आपके साझा डेटा को एक समय में केवल एक थ्रेड द्वारा एक्सेस किया जाता है। आपको साझा डेटा पर क्रमिक पहुंच सुनिश्चित करना होगा, साथ ही दौड़ की स्थिति से बचने के लिए, deadlocks , livelocks , और संसाधन भुखमरी

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

0
जोड़ा

विकिपीडिया से:

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

...

थ्रेड सुरक्षा प्राप्त करने के कुछ तरीके हैं:

Re-entrancy

कोड को इस तरह से लिखना कि इसे एक कार्य द्वारा आंशिक रूप से निष्पादित किया जा सकता है, किसी अन्य कार्य द्वारा पुन: प्रस्तुत किया जा सकता है, और उसके बाद मूल कार्य से फिर से शुरू किया जा सकता है। इसके लिए स्थिर या वैश्विक चर के बजाय, प्रत्येक कार्य के लिए स्थानीय रूप से चर के रूप में राज्य की जानकारी की बचत की आवश्यकता होती है।

Mutual exclusion

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

Thread-local storage

वेरिएबल्स को स्थानीयकृत किया जाता है ताकि प्रत्येक थ्रेड की अपनी निजी प्रति हो। ये चर subroutine और अन्य कोड सीमाओं में अपने मान बनाए रखते हैं, और थ्रेड-सुरक्षित हैं क्योंकि वे प्रत्येक थ्रेड के लिए स्थानीय हैं, भले ही उन्हें एक्सेस करने वाला कोड पुनर्वित्त हो।

Atomic operations

Shared data are accessed by using atomic operations which cannot be interrupted by other threads. This usually requires using special machine language instructions, which might be available in a runtime library. Since the operations are atomic, the shared data are always kept in a valid state, no matter what other threads access it. Atomic operations form the basis of many thread locking mechanisms.

और पढ़ें:

http://en.wikipedia.org/wiki/Thread_safety


0
जोड़ा
आपका मतलब क्या है "एक फंक्शन तक पहुंचने वाला कोड"? फ़ंक्शन निष्पादित किया जा रहा है कोड है, है ना?
जोड़ा लेखक Koray Tugay, स्रोत
वर्णनात्मक उत्तर। अधिकांश अन्य उत्तरों भी सही हैं। सबको धन्यवाद
जोड़ा लेखक Varun Mahajan, स्रोत
यह लिंक तकनीकी रूप से कई महत्वपूर्ण बिंदुओं को याद कर रहा है। प्रश्न में साझा स्मृति उत्परिवर्तनीय होनी चाहिए, (केवल-पढ़ने वाली स्मृति थ्रेड-असुरक्षित नहीं हो सकती है), और एकाधिक धागे आवश्यक हैं, ए) स्मृति के दौरान स्मृति पर एकाधिक लेखन संचालन करें, जिसमें स्मृति एक असंगत (गलत) है राज्य, और बी) स्मृति के असंगत होने पर अन्य धागे को उस थ्रेड को बाधित करने की अनुमति दें।
जोड़ा लेखक Charles Bretana, स्रोत
जब Google की खोज पहली बार विकी है, तो इसे यहां अनावश्यक बनाने का कोई मतलब नहीं है।
जोड़ा लेखक Ranvir, स्रोत

थ्रेड-सुरक्षित कोड कोड है जो काम करेगा, भले ही कई थ्रेड इसे एक साथ निष्पादित कर रहे हों।

http://mindprod.com/jgloss/threadsafe.html

0
जोड़ा
@ जोन, .. मुझे लगता है कि किसी भी समय कोड का एक ब्लॉक जो किसी अन्य थ्रेड द्वारा सुलभ (और संशोधित-सक्षम) संसाधन में एक आविष्कार बनाता है, चाहे वह अन्य थ्रेड उसी प्रक्रिया में या किसी अन्य प्रक्रिया में निष्पादित किया जा रहा हो , हम "बहु थ्रेडिंग" हैं। जब तक स्पष्ट रूप से कोड नहीं किया जाता है, तब तक सभी आधुनिक ओएस बहु-प्रसंस्करण को लागू करने के लिए चल रहे कोड को बाधित कर सकते हैं (और करते हैं)।
जोड़ा लेखक Charles Bretana, स्रोत
@ mg30rg, अगर यह "विफल रहता है जब प्रति थ्रेड एक थ्रेड इसे निष्पादित करता है और वे प्रक्रियाएं एक साथ चलती हैं," तो यह "थ्रेड सुरक्षित" नहीं है। आपका कथन सत्य होगा यदि एक थ्रेड केवल एक प्रक्रिया में निष्पादित करता है, तो यह बस असुरक्षित है। यदि यह विफल रहता है जब एकाधिक धागे इसे एक साथ निष्पादित करते हैं, ("एक साथ" नहीं) लेकिन केवल एक समवर्ती धागे में निष्पादित होने पर समान विफलता का अनुभव नहीं किया जा सकता है, तो यह थ्रैड असुरक्षित है।
जोड़ा लेखक Charles Bretana, स्रोत
@ Mg30rg। शायद भ्रम किसी भी तरह से सोचने का नतीजा है कि जब कई प्रक्रियाओं द्वारा कोड का एक ब्लॉक निष्पादित किया जा रहा है, लेकिन केवल एक थ्रेड प्रति प्रक्रिया द्वारा, कि, किसी भी तरह से अभी भी एक "सिंगल थ्रेडेड" परिदृश्य है, न कि एकाधिक थ्रेडेड परिदृश्य । यह विचार भी गलत नहीं है। यह सिर्फ गलत परिभाषा है। स्पष्ट रूप से, एकाधिक प्रक्रियाएं आमतौर पर एक ही थ्रेड पर एक सिंक्रनाइज़ तरीके से निष्पादित नहीं होती हैं, (दुर्लभ परिदृश्यों को छोड़कर जहां एक दूसरे के साथ डिजाइन समन्वय द्वारा प्रक्रियाएं और ओएस प्रक्रियाओं के बीच थ्रेड साझा करता है।)
जोड़ा लेखक Charles Bretana, स्रोत
ओह! यह जवाब सिर्फ सवाल को बहाल करता है! --- और क्यों केवल एक ही प्रक्रिया में ??? यदि कोड विफल रहता है जब एकाधिक थ्रेड इसे विभिन्न प्रक्रियाओं से निष्पादित करते हैं, तो तर्कसंगत रूप से, ("साझा स्मृति" डिस्क फ़ाइल में हो सकती है), यह थ्रेड सुरक्षित नहीं है !!
जोड़ा लेखक Charles Bretana, स्रोत
@ mrg30rg, यदि लिनक्स "... धागे की बजाय प्रक्रियाओं के बीच बैच की गई समस्याओं को वितरित करता है ..." तो वे अलग धागे पर हैं। केवल एक धागे पर दो अलग-अलग प्रक्रियाएं कैसे चल सकती हैं? वे तब तक नहीं कर सकते जब तक कि वे किसी भी तरह सिंक्रनाइज़ नहीं होते हैं (जैसे मशीन पर एक बहु-प्रोसेस ओएस चलाने पर केवल एक सीपीयू)। लेकिन उस स्थिति में, एकल "थ्रेड" जो कुछ भी चल रहा है वह उस धागे की तुलना में बहुत अधिक स्तर पर एक तार्किक अमूर्त है जिस पर हम चर्चा कर रहे हैं।
जोड़ा लेखक Charles Bretana, स्रोत
एक ही प्रक्रिया के भीतर!
जोड़ा लेखक Ali Afshar, स्रोत
"कोड लिखने के लिए जो सप्ताह के लिए स्थिर रूप से चलेंगे चरम परावर्तक लेता है।" यह एक उद्धरण है जो मुझे पसंद है :)
जोड़ा लेखक Jim T, स्रोत
दरअसल, एक ही प्रक्रिया में :)
जोड़ा लेखक Marek Blotny, स्रोत
@ चार्ल्सब्रेटाना "स्पष्ट रूप से, एकाधिक प्रक्रियाएं एक ही थ्रेड पर सिंक्रनाइज़ तरीके से निष्पादित नहीं होती हैं" मुझे लगता है कि यह कथन केवल विंडोज़ (या अधिक आम तौर पर बहुप्रचारित) में सत्य है ) वातावरण, लेकिन लिनक्स (या आमतौर पर मल्टीप्रोसेस में अधिक) वातावरण में सत्य होने में विफल रहता है, क्योंकि बाद में धागे की बजाय प्रक्रियाओं के बीच बैच की गई समस्याओं को वितरित करता है। डिस्कलीमर: दोनों मल्टीप्रोसेसिंग और मल्टीथ्रेडिंग दोनों उल्लिखित ओएस पर उपलब्ध हैं, केवल वे मुझे संबोधित तरीके से बेहतर प्रदर्शन करते हैं। #noOSflamepls
जोड़ा लेखक mg30rg, स्रोत
@CharlesBretana यदि कोड ( सेगमेंट ) विफल रहता है यदि कई थ्रेड इसे विभिन्न प्रक्रियाओं में एक साथ निष्पादित कर रहे हैं, तो यह होगा विफल हो सकता है यदि एक प्रति प्रक्रिया धागा इसे निष्पादित करता है और उन प्रक्रियाओं को एक साथ चलाता है, ताकि कोड (सेगमेंट) थ्रेड सुरक्षा की कमी नहीं है , लेकिन < बी> बस असुरक्षित ।
जोड़ा लेखक mg30rg, स्रोत
बस ध्यान दें कि यहां @ चार्ल्सब्रेटाना संभावित रूप से मल्टीप्रोसेसिंग परिदृश्यों को कवर करने के लिए 'थ्रेड' की एक और अधिक वैचारिक (और अंतर्ज्ञानी?) परिभाषा का उपयोग कर रहा है जहां कोई वास्तविक थ्रेडिंग शामिल नहीं है। (पायथन में, थ्रेड या साझा मेमोरी/डिस्क के बिना ऐसा करने के लिए पूरे ढांचे हैं बल्कि मसालेदार वस्तुओं को संदेश के रूप में पास करके।)
जोड़ा लेखक Jon Coombs, स्रोत

बस - अगर कोड एक ही समय में इस कोड को निष्पादित कर रहे हैं तो कोड ठीक हो जाएगा।

0
जोड़ा

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

ध्यान दें कि परिणामों की अप्रत्याशितता 'दौड़-परिस्थितियों' का परिणाम है जो शायद परिणामस्वरूप अपेक्षित व्यक्ति के अलावा किसी अन्य क्रम में संशोधित की जा रही है।

0
जोड़ा

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

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

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

0
जोड़ा

सरल शब्दों में: पी  यदि कोड के ब्लॉक पर एकाधिक धागे निष्पादित करना सुरक्षित है तो यह थ्रेड सुरक्षित है *

*शर्तें लागू

अन्य उत्तरदाताओं द्वारा शर्तों का उल्लेख किया गया है 1. परिणाम एक जैसा होना चाहिए यदि आप इसे एक थ्रेड या एकाधिक थ्रेड निष्पादित करते हैं।

0
जोड़ा