2009-02-18 14 views
6

कहें कि मेरे पास तीन थ्रेड हैं जिन्हें संग्रह तक पहुंच की आवश्यकता है और मैं प्रत्येक थ्रेड में एक्सेस के चारों ओर लॉक ब्लॉक का उपयोग करता हूं। निम्न होता है ...लॉक स्टेटमेंट सी #

(1) थ्रेड 1 संग्रह पर ताला हो जाता है
(2) थ्रेड 2 अवरुद्ध हो जाता है
(3) थ्रेड 3 अवरुद्ध हो जाता है

जब थ्रेड 1 रिलीज ताला, अगले लॉक कौन लेता है? क्या यह फीफो का उपयोग है?

धन्यवाद

उत्तर

17

आप जो ताला अगले हो जाता है परवाह नहीं करनी चाहिए।

+2

आप इसे कहने के लिए बढ़ा सकते हैं * देखभाल नहीं कर सकते। शायद। – JMD

+0

मुझे एहसास है कि मुझे धागे को प्रोग्राम करना चाहिए ताकि मुझे परवाह न हो, मैं बस सोच रहा हूं कि तंत्र क्या है। –

+2

http://msdn.microsoft.com/en-us/library/aa645740(VS.71).aspx#vcwlkthreadingtutorialexample4mutex "नमूना चलाने वाली मशीन की गति और ऑपरेटिंग सिस्टम आउटपुट ऑर्डर को प्रभावित कर सकती है।" –

4

मान लीजिए कि यह Win32 की तरह है तो जवाब यह है कि यह फीफो हो सकता है लेकिन यह नहीं हो सकता है (यह कुछ और हो सकता है)। उदाहरण के लिए, एक उच्च प्राथमिकता धागा पहले होना चाहिए; लेकिन धागे हाल ही में जो कुछ भी कर रहे हैं उसके आधार पर उनकी प्राथमिकता में अस्थायी वृद्धि या गिरावट प्राप्त कर सकते हैं।

+0

जो मैंने पढ़ा है, उससे यह सही है। लॉक को एफआईएफओ के बारे में सोचा जा सकता है, लेकिन इसकी गारंटी नहीं है। –

5

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

Monitor/lock which remember order in C# to simulate FIFO

जैसा कि पहले ही अन्य उत्तर में उल्लेख किया है कि वहाँ कोई गारंटी आदेश धागे इंतजार कर रहे एक ताला प्राप्त होगा।

+0

दुर्भाग्य से लिंक टूटा हुआ। –

4

आपके प्रश्न के उत्तर के रूप में, सभी थ्रेड मॉनिटर.pulse प्राप्त करते हैं जो तब लॉक हो जाता है जो आगे लॉक हो जाता है।

मेरा मानना ​​है कि विंटलेलेक्ट के लोगों ने एक ब्लॉग लिखा है कि यह व्यवहार एक अनुचित स्थिति का कारण बन सकता है, लेकिन मॉनिटर में बिल्कुल कोई निष्पक्षता नहीं है।

3

उत्तर परिभाषा, अनिश्चित है।

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