GUI प्रोग्रामिंग में थ्रेड सुरक्षा सुनिश्चित करने के लिए कॉलर की जिम्मेदारी क्यों है?


37

मैंने कई स्थानों पर देखा है, कि यह विहित ज्ञान 1 है कि यह यूआई थ्रेड पर यूआई थ्रेड को अपडेट करने के लिए सुनिश्चित करने के लिए कॉलर की जिम्मेदारी है (विशेष रूप से, जावा स्विंग में, कि आप ईवेंट डिस्पैच थ्रेड पर हैं ) ।

ऐसा क्यों है? इवेंट डिस्पैच थ्रेड MVC / MVP / MVVM में दृश्य की चिंता का विषय है ; इसे कहीं भी संभालने के लिए लेकिन दृश्य दृश्य के कार्यान्वयन और उस दृश्य के कार्यान्वयन के थ्रेडिंग मॉडल के बीच एक तंग युग्मन बनाता है ।

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

इसलिए, मुझे लगता है कि मेरे दो सवाल हैं:

  1. UI घटक थ्रेड सुरक्षा सुनिश्चित करने के लिए कॉलर की जिम्मेदारी क्यों है? ऊपर मेरे तर्क में दोष कहां है?
  2. मैं इन थ्रेड सुरक्षा चिंताओं के ढीले युग्मन के लिए अपने आवेदन को कैसे डिज़ाइन कर सकता हूं, फिर भी उचित रूप से थ्रेड-सुरक्षित हो सकता है?

मुझे "कॉल करने वाले ज़िम्मेदार" से जो मतलब है उसे दर्शाने के लिए कुछ MCVE जावा कोड जोड़ें (यहाँ कुछ अन्य अच्छे अभ्यास हैं जो मैं नहीं कर रहा हूँ लेकिन मैं यथासंभव कम से कम होने के उद्देश्य से कोशिश कर रहा हूँ):

कॉल करने वाला जिम्मेदार:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}
public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

जिम्मेदार देखें:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}
public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

1: उस पोस्ट के लेखक का Swing on Stack Overflow में सर्वोच्च टैग स्कोर है। वह यह सब जगह कहते हैं और मैंने इसे अन्य स्थानों में भी कॉलर की जिम्मेदारी के रूप में देखा है।


1
एह, प्रदर्शन IMHO। वे ईवेंट पोस्टिंग मुफ्त में नहीं आते हैं, और गैर-तुच्छ ऐप्स में आप उनकी संख्या को कम करना चाहते हैं (और सुनिश्चित करें कि कोई भी बहुत बड़ा नहीं है), लेकिन यह कि न्यूनतम / संक्षेपण प्रस्तुतकर्ता में तार्किक रूप से किया जाना चाहिए।
आयुध

1
@ ऑर्डस आप यह सुनिश्चित कर सकते हैं कि दृश्य में थ्रेड हैंडऑफ़ डालते समय पोस्टिंग न्यूनतम हो।
डुर्रोन 597

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

1
SWT अपवादों को फेंककर थ्रेड सुरक्षा की अवधारणा को लागू करता है यदि आपका उल्लंघन करता है, तो यह सुंदर नहीं है, लेकिन कम से कम आपको इसके बारे में पता है। आप झूले से बदलकर JavaFX का उल्लेख करते हैं, लेकिन आपको किसी भी UI फ्रेमवर्क के बारे में यह समस्या होगी, झूलना सिर्फ ऐसा लगता है जो समस्या को उजागर करता है। आप एक मध्यवर्ती परत (एक नियंत्रक का नियंत्रक?) डिजाइन कर सकते हैं जिसका काम यह सुनिश्चित करना है कि यूआई को कॉल सही ढंग से सिंक्रनाइज़ हो। यह जानना असंभव है कि आप अपने एपीआई के गैर-यूआई भागों को यूआई एपीआई के परिप्रेक्ष्य से कैसे डिजाइन कर सकते हैं
MadProgrammer

1
और अधिकांश डेवलपर्स शिकायत करते हैं कि UI API में कार्यान्वित किसी भी थ्रेड सुरक्षा को प्रतिबंधित करना या उनकी आवश्यकताओं को पूरा नहीं करना था। अपनी जरूरतों के आधार पर आप यह तय करने की अनुमति देना चाहते हैं कि आप इस मुद्दे को कैसे हल करना चाहते हैं
MadProgrammer

जवाबों:


22

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

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

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

ध्यान दें कि इस प्रकार के मुद्दे सभी GUI टूलकिट के लिए सार्वभौमिक हैं। अपने प्रस्तोता / नियंत्रक में एक घटना प्रेषण मॉडल को मानते हुए आप केवल एक विशिष्ट GUI टूलकिट के संगामिति मॉडल पर युग्मन नहीं कर रहे हैं, यह आपको उन सभी के लिए युग्मित कर रहा है । ईवेंट कतारबद्ध इंटरफ़ेस सार के लिए कठिन नहीं होना चाहिए।


25

क्योंकि GUI के लिबास को सुरक्षित बनाना एक भारी सिरदर्द और अड़चन है।

GUIs में नियंत्रण प्रवाह अक्सर इवेंट दिशाओं से रूट विंडो से gui विजेट्स तक 2 दिशाओं में जाता है और एप्लिकेशन कोड से विजेट तक रूट विंडो तक प्रचारित होता है।

लॉकिंग रणनीति को तैयार करना जो रूट विंडो को लॉक नहीं करता है (बहुत विवाद का कारण होगा) मुश्किल है । एक और थ्रेड को ऊपर से लॉक करते हुए नीचे लॉक करना तात्कालिक गतिरोध को प्राप्त करने का एक शानदार तरीका है।

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


1
दिलचस्प बात यह है कि मैं इन अपडेट के लिए एक कतारबद्ध रूपरेखा बनाकर इस समस्या को हल करता हूं जो मैंने लिखा था कि थ्रेड हैंडऑफ़ का प्रबंधन करता है।
डुर्रोन 597

2
@ durron597: और UI की वर्तमान स्थिति के आधार पर आपके पास कोई भी अपडेट कभी भी अपडेट नहीं होगा जो किसी अन्य थ्रेड को प्रभावित कर सकता है? तब यह काम कर सकता है।
डेडुप्लिकेटर

आपको नेस्टेड ताले की आवश्यकता क्यों होगी? बच्चे की खिड़की में विवरण पर काम करते समय आपको पूरी रूट विंडो को लॉक करने की आवश्यकता क्यों है? लॉक ऑर्डर सही क्रम में (या तो टॉप-डाउन या बॉटम-अप, लेकिन
लॉक

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

@ratchetfreak: यदि आप जिस बच्चे को लॉक करने की कोशिश करते हैं, उसे लॉक करते समय दूसरे धागे से हटा दिया जाता है, यह सिर्फ थोड़ा दुर्भाग्यपूर्ण है लेकिन लॉकिंग के लिए प्रासंगिक नहीं है। आप बस एक ऐसी वस्तु पर काम नहीं कर सकते हैं जिसे एक और धागा अभी हटा दिया गया है। लेकिन क्यों अन्य धागा वस्तुओं / खिड़कियों को हटा रहा है जो आपका धागा अभी भी उपयोग कर रहा है? यह किसी भी परिदृश्य में अच्छा नहीं है, न कि केवल यूआई।
एमएसल्टर्स

17

थ्रेडेडनेस (एक साझा मेमोरी मॉडल में) एक संपत्ति है जो अमूर्त प्रयासों को धता बताती है। एक साधारण उदाहरण एक है Setप्रकार है: Contains(..)और Add(...)और Update(...)एक भी लड़ी परिदृश्य में एक पूरी तरह से वैध एपीआई, मल्टी-थ्रेडेड परिदृश्य एक की जरूरत है AddOrUpdate

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

  1. टूलकिट उस समस्या को हल नहीं कर सकता है क्योंकि लॉकिंग सुनिश्चित नहीं करता है कि संचालन का क्रम सही रहता है।
  2. दृश्य समस्या को हल कर सकता है, लेकिन केवल अगर आप व्यापार नियम को अनुमति देते हैं कि सूची के शीर्ष पर स्थित सूची में आइटम की संख्या से मेल खाना है और केवल दृश्य के माध्यम से सूची को अपडेट करें। ऐसा बिल्कुल नहीं है कि MVC माना जाता है।
  3. प्रस्तुतकर्ता इसे हल कर सकता है, लेकिन यह जानने की जरूरत है कि थ्रेडिंग के संबंध में दृश्य की विशेष आवश्यकताएं हैं।
  4. मल्टी-थ्रेडिंग सक्षम मॉडल के लिए डेटाबाइंडिंग एक और विकल्प है। लेकिन यह उन चीजों के साथ मॉडल को जटिल करता है जो यूआई-चिंताएं होनी चाहिए।

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


हो सकता है कि व्यू और प्रस्तुतकर्ता के बीच एक परत पेश की जा सकती है जिसे स्वैप भी किया जा सकता है।
डुर्रोन 597

2
.NET को System.Windows.Threading.DispatcherWPF और WinForms UI- थ्रेड्स दोनों को भेजने का काम संभालना है। प्रस्तुतकर्ता और दृश्य के बीच उस तरह की परत निश्चित रूप से उपयोगी है। लेकिन यह केवल टूलकिट स्वतंत्रता प्रदान करता है, स्वतंत्रता का प्रसार नहीं करता है।
पैट्रिक

9

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

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

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

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

आप झूले से बदलकर JavaFX का उल्लेख करते हैं, लेकिन आपको यह समस्या किसी भी UI फ्रेमवर्क (न केवल मोटे क्लाइंट, बल्कि वेब के साथ) के बारे में भी होगी, स्विंग केवल वह लगती है जो समस्या को उजागर करती है।

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

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

ठीक है, आप इसे किसी प्रकार की कतार के द्वारा हल कर सकते हैं, जो उस समय के आधार पर घटनाओं को जारी करने का आदेश देता है, लेकिन ऐसा नहीं है कि हमारे पास पहले से क्या है? इसके अलावा, आप अभी भी इस बात की कोई गारंटी नहीं दे सकते हैं कि थ्रेड बी यह घटनाओं के बाद उत्पन्न होगा धागा ए

लोगों को अपने कोड के बारे में सोचने के लिए परेशान होने का मुख्य कारण है, क्योंकि वे अपने कोड / डिज़ाइन के बारे में सोचने के लिए बने हैं। "यह सरल क्यों नहीं हो सकता है?" यह सरल नहीं हो सकता, क्योंकि यह एक साधारण समस्या नहीं है।

मुझे याद है कि जब PS3 जारी किया गया था और सोनी सेल प्रोसेसर से बात कर रहा था और यह लॉजिक, डिकोड, ऑडियो, वीडियो, लोड और मॉडल डेटा को अलग करने की अलग-अलग लाइनें करने की क्षमता है। एक गेम डेवलपर ने पूछा, "यह सब बहुत बढ़िया है, लेकिन आप धाराओं को कैसे सिंक्रनाइज़ करते हैं?"

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

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

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

फिर आप इन विभिन्न परतों के निर्माण के लिए इंटरफ़ेस डिज़ाइन पैटर्न और फ़ैक्टरी या बिल्डर पैटर्न के लिए कोडिंग का उपयोग करेंगे। इसका मतलब है, कि आप एक विचार के रूप में, एक मध्यम परत के उपयोग के माध्यम से यूआई परत से बहुस्तरीय रूपरेखाओं का डिकॉउंड हो जाते हैं।


2
आपको वेब के साथ यह समस्या नहीं होगी। जावास्क्रिप्ट में जानबूझकर कोई थ्रेडिंग समर्थन नहीं है - एक जावास्क्रिप्ट रनटाइम प्रभावी रूप से सिर्फ एक बड़ी घटना कतार है। (हां, मुझे पता है कि सख्ती से बोलने वाले JS के पास WebWorkers हैं - ये नीयर थ्रेड हैं, और अन्य भाषाओं में अभिनेताओं की तरह अधिक व्यवहार करते हैं)।
जेम्स_पिक

1
@James_pic आपके पास वास्तव में क्या ब्राउज़र का हिस्सा है जो इवेंट क्यू के लिए सिंक्रोनाइज़र के रूप में कार्य करता है, जो कि मूल रूप से हम जिस बारे में बात कर रहे हैं, कॉलर टूलकिट ईवेंट कतार के साथ अपडेट सुनिश्चित करने के लिए ज़िम्मेदार था
Madgramgrammer

हाँ बिल्कुल। वेब के संदर्भ में, महत्वपूर्ण अंतर यह है कि यह सिंक्रनाइज़ेशन कॉलर के कोड के बावजूद होता है, क्योंकि रनटाइम कोई तंत्र प्रदान नहीं करता है जो इवेंट कतार के बाहर कोड निष्पादन की अनुमति देगा। इसलिए फोन करने वाले को इसकी जिम्मेदारी नहीं लेनी चाहिए। मेरा मानना ​​है कि NodeJS के विकास के पीछे प्रेरणा का एक बड़ा हिस्सा है - यदि रनटाइम वातावरण एक ईवेंट लूप है, तो सभी कोड डिफ़ॉल्ट रूप से ईवेंट लूप है।
जेम्स_पिक

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

क्या "डिस्प्ले-ओनली" नियंत्रण के साथ कोई विशेष समस्या होगी, जो थ्रेड-सुरक्षा को स्वचालित रूप से प्रदान करती है? यदि किसी के पास एक संपादन योग्य पाठ नियंत्रण होता है जो एक धागे से लिखा जाता है और दूसरे द्वारा पढ़ा जाता है, तो कोई अच्छा तरीका नहीं है कि कोई भी लिख सकता है कि नियंत्रण के वास्तविक UI स्थिति में उन कार्यों में से कम से कम एक को सिंक्रनाइज़ किए बिना लिखा जा सकता है, लेकिन क्या केवल प्रदर्शन के नियंत्रण के लिए ऐसा कोई मुद्दा होगा? मुझे लगता है कि वे आसानी से उन पर किए गए संचालन के लिए किसी भी आवश्यक लॉकिंग या इंटरलॉक को प्रदान कर सकते हैं, और कॉल करने वाले को समय की अनदेखी करने की अनुमति देते हैं ...
सुपरकैट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.