वेब अनुप्रयोगों में 'लॉक' का उपयोग

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

मुझे कोड ब्लॉक को पूरी तरह से याद नहीं है, लेकिन इसे समेटने के लिए यह एक वेब हिट काउंटर था, और उसने हिट काउंटर पर लॉक का उपयोग किया।

lock(HitCounter) 
{ 
    // Bla... 
}

हालांकि कुछ चर्चा के बाद उन्होंने कहा, लॉक अच्छा है लेकिन वेब अनुप्रयोगों में इसका कभी भी उपयोग नहीं करते!

उनके बयान के पीछे आधार क्या है? मैं वेब अनुप्रयोगों में लॉक का उपयोग क्यों नहीं करना चाहिए?

स्रोत

2010-11-30 kyndigs

वेब ऐप्स विशेष रूप से विशेष नहीं हैं, सिवाय इसके कि उन्हें अक्सर अत्यधिक समवर्ती होने की आवश्यकता होती है। जब भी आवश्यक हो, आपको 'लॉक' का उपयोग करना चाहिए - आवेदन के प्रकार के बावजूद, कोई और नहीं, कम नहीं। – LukeH

हिट काउंटर एक वर्ग या एक उदाहरण है? –

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

आधुनिक हार्डवेयर an uncontended lock takes 20 nanoseconds to flip पर हमेशा याद रखने योग्य क्या है। इस बात को ध्यान में रखते हुए, जितना संभव हो सके लॉक ब्लॉक के अंदर कोड बनाने की कोशिश करने का सामान्य अभ्यास किया जाना चाहिए। यदि आपके पास ब्लॉक के भीतर न्यूनतम कोड है, तो ओवरहेड काफी छोटा है और विवाद के लिए संभावित है।

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

अंत में, बीसीएल और एएसपी.Net फ्रेमवर्क प्रकार निश्चित रूप से आंतरिक रूप से ताले का उपयोग करते हैं, इसलिए आप अप्रत्यक्ष रूप से उनका उपयोग कर रहे हैं।

स्रोत

2010-11-30 14:55:26

एप्लिकेशन डोमेन को पुनर्नवीनीकरण किया जा सकता है।

इसका परिणाम हो सकता है कि पुराना ऐपडोमेन अभी भी कुछ अनुरोधों को पूरा कर रहा है और नया ऐपडोमेन भी नए अनुरोधों की सेवा कर रहा है।

स्टेटिक चर उनके बीच साझा नहीं किए जाते हैं, इसलिए स्थिर वैश्विक पर लॉक करना इस मामले में विशिष्टता प्रदान नहीं करेगा।

स्रोत

2010-11-30 14:32:22

यह कोड आपके आवेदन के लिए एक बाधा उत्पन्न करेगा क्योंकि सभी आने वाले अनुरोध को लॉक से बाहर जाने से पहले इस बिंदु पर इंतजार करना होगा।

स्रोत

2010-11-30 14:32:33 VdesmedT

अभी भी, यह वेब ऐप्स के लिए विशिष्ट नहीं है, है ना? – xtofl

@xtofl - यह वेब ऐप्स के लिए विशिष्ट नहीं है, लेकिन पृष्ठ एक वेब ऐप में एक बिंदु है जिसे हर उपयोगकर्ता संभावित रूप से एक्सेस करेगा। अन्य ऐप्स में तालाबों का उपयोग कम से कम, और उन क्षेत्रों में किया जा सकता है जो कम प्रभाव वाले हैं। –

यह आने वाले अनुरोध की सेवा के लिए अलग-अलग थ्रेड का उपयोग करके किसी भी एप्लिकेशन के लिए विशिष्ट है और जहां सभी थ्रेड इस कोड को गुजरेंगे। वेब एप्स ऐसे का एक अच्छा उदाहरण हैं। क्या यह ? – VdesmedT

सबसे पहले, आप कभी भी उस ऑब्जेक्ट को लॉक नहीं करना चाहते जिसे आप वास्तव में किसी भी एप्लिकेशन में उपयोग करते हैं। आपको एक लॉक वस्तु बना सकते हैं और लॉक करना चाहते हैं कि:

private readonly object _hitCounterLock = new object(); 
lock(_hitCounterLock) 
{ 
    //blah 
}

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

स्रोत

2010-11-30 14:33:32

दूसरा, आपको उस संदर्भ पर कभी भी लॉक नहीं करना चाहिए जो पढ़ा नहीं जाता है। –

भी सच है :-) मुझे याद दिलाने के लिए धन्यवाद। अभी अपडेट हो रहा है –

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

वेब अनुप्रयोगों में

, उपयोगकर्ता अनुरोधों अलग हो जाती हैं तो

स्रोत

2010-11-30 14:38:02

वेब ऐप्स निश्चित रूप से बहु थ्रेड ऐप्स हैं जो कई अनुरोधों को एक साथ सेवा करने की अनुमति देते हैं। – VdesmedT

ऐसा लगता है कि आपने बिंदु नहीं उठाया है। मैंने कहा कि अनुरोध एक-दूसरे से पृथक हैं जिसका मतलब है कि सामान्य मामले में साझा या एप्लिकेशन चौड़ा स्कोप चर का उपयोग किए बिना लॉकिंग की आवश्यकता नहीं होती है। –

हाँ, मुझे नहीं पता कि लोगों को उस अवधारणा में परेशानी क्यों है। लोगों को लगता है कि "वेब ऐप्स पर ताले का उपयोग न करें" का अर्थ है "वेब ऐप्स पर ताले बुरा हैं"। मुद्दा यह है कि आपको लॉक का उपयोग शुरू करने के लिए लगभग कभी भी कारण नहीं होना चाहिए। मेरा इसी तरह का जवाब भी नीचे मतदान किया गया। –

युगल कारणों ... डिफ़ॉल्ट रूप से लॉक करने के लिए कोई जरूरत नहीं है

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

स्रोत

2010-11-30 14:48:13

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

प्वाइंट 2 ताले डोमेन विशिष्ट नहीं हैं, इसलिए कोई "सामान्य" अनुप्रयोग प्रकार का उपयोग नहीं है। –

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

देर :), लेकिन इस के भविष्य के पाठकों, एक अतिरिक्त अंक के लिए:

आवेदन एक वेब खेत पर चलाया जाता है, तो कई मशीनों पर एएसपी चल रहा है ताला वस्तु

तो साझा नहीं करेंगे यह केवल तभी काम कर सकता है जब 1. कोई वेब फार्म समर्थित नहीं होना चाहिए और 2. एएसपी कॉन्फ़िगर किया गया है (गैर-डिफ़ॉल्ट) रीसायकल के दौरान समांतर उदाहरणों का उपयोग न करने के लिए पुराने अनुरोधों (जैसा कि ऊपर एंड्रॉज द्वारा उल्लिखित है)

स्रोत

2015-02-26 18:40:38 Dani

वेब अनुप्रयोगों में 'लॉक' का उपयोग

उत्तर

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