एकाधिक पाठकों के लिए सिंक्रनाइज़ेशन, एकल लेखक?

Question

एक और तुल्यकालन सवाल ... मुझे आशा है कि आप लोग परेशान हो जाते नहीं है;)

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

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

क्या इस तरह के परिदृश्य को हल करने के लिए एक अच्छा और सुरुचिपूर्ण तरीका है?

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

संपादित करें 2: मैं सिर्फ एक लेखक/एकाधिक पाठकों में से एक कार्यान्वयन में देखा - ताला और इस कार्यान्वयन एक मॉनिटर का उपयोग करता WaitToRead विधि में कुछ कोड सिंक्रनाइज़ करने के लिए। क्या यह वही धारावाहिक प्रभाव नहीं है जिसे मैं पहली जगह से बचना चाहता था? (फिर भी यह मानते हुए कि कोड सिंक्रनाइज़ किया जाना छोटा और तेज़ है)

Answer 1

RTL में उस उद्देश्य के लिए एक वर्ग नहीं है (sysutils): TMultiReadExclusiveWriteSynchroniser

इसका उपयोग करना बहुत आसान है। आपको पाठकों या लेखक जैसे अपने धागे को सख्ती से वर्गीकृत करने की आवश्यकता नहीं है। थ्रेड सुरक्षित ऑपरेशन शुरू करने के लिए बस थ्रेड में "BeginRead" या "BeginWrite" को कॉल करें। ऑपरेशन को खत्म करने के लिए "एंड्र्रेड" या "एंडवाइट" पर कॉल करें।

Answer 2

जब भी लेखक पहुंचना चाहता है, तो आप आने वाले पाठकों को घेर लेते हैं (उन्हें कंडीशन पर इंतजार कर सकते हैं), सक्रिय पाठकों को समाप्त करने, लिखने और समाप्त होने की प्रतीक्षा करें प्रबुद्ध पाठकों का उपयोग।

Answer 3

आप msdn magazine और excerpt from Programming applications for MS windows पर इस समस्या को हल करने के लिए कुछ विस्तृत नोट्स पा सकते हैं।

Answer 4

जो आप खोज रहे हैं (और क्या वर्टेक वर्णित है) को Reader(s)-Writer-Lock कहा जाता है।

Answer 5

रीडर-राइटर लॉक का उपयोग समस्या को हल करेगा। एकाधिक पाठक एक डेटाबेस तक पहुंच सकते हैं और सभी पाठकों को पढ़ने के बाद एक लेखक को लॉक मिल जाता है।

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

Answer 6

पाठक-लेखक लॉक आपको जो चाहिए वह है। Tutorial में एक विवरण है, लेकिन मुझे यकीन है कि कोई इसे डेल्फी के मानक के रूप में जोड़ रहा था। डी 2009 की जांच करने लायक हो सकता है यह पहले से ही नहीं है।

Answer 7

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

ध्यान दें कि पाठक-लेखक-लॉक जैसे महत्वपूर्ण वर्गों की तुलना में अधिक चालाक सिंक्रनाइज़ेशन का उपयोग करना, starvation समस्याओं को पेश कर सकता है जो डीबग और ठीक करना मुश्किल हो सकता है। आपको वास्तव में कठोर दिखने की आवश्यकता है कि बढ़ी हुई थ्रूपुट संभावित समस्याओं से अधिक है या नहीं। ध्यान दें कि वास्तव में थ्रूपुट में वृद्धि नहीं हो सकती है, खासकर यदि लॉक कोड बहुत छोटा और तेज़ है। वहाँ एक nice article by Jeffrey Richter है कि वास्तव में इस उद्धरण शामिल है:

प्रदर्शन यहां तक ​​कि जब वहाँ एक ReaderWriterLock के लिए कोई विवाद है, इसके प्रदर्शन बहुत धीमी है। उदाहरण के लिए, मॉनिटर की एंटर विधि पर कॉल से निष्पादित करने के लिए इसकी AcquireReaderLock विधि को कॉल करने में लगभग पांच गुना अधिक समय लगता है।

यह पाठ्यक्रम के .NET के लिए है, लेकिन अंतर्निहित सिद्धांत भी लागू होते हैं।