क्या रिटर्न स्टेटमेंट लॉक के अंदर या बाहर होना चाहिए?

Question

मुझे अभी एहसास हुआ कि मेरे कोड में किसी स्थान पर मेरे पास लॉक के अंदर रिटर्न स्टेटमेंट है और कभी-कभी बाहर है। कौन सा सबसे अच्छा है?

1)

void example() 
{ 
    lock (mutex) 
    { 
    //... 
    } 
    return myData; 
} 

2)

void example() 
{ 
    lock (mutex) 
    { 
    //... 
    return myData; 
    } 

} 

एक कौन सा उपयोग करना चाहिए?

Answer 1

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

आईएल में अंतर दिखाने के लिए, की सुविधा देता है कोड:

static class Program 
{ 
    static void Main() { } 

    static readonly object sync = new object(); 

    static int GetValue() { return 5; } 

    static int ReturnInside() 
    { 
     lock (sync) 
     { 
      return GetValue(); 
     } 
    } 

    static int ReturnOutside() 
    { 
     int val; 
     lock (sync) 
     { 
      val = GetValue(); 
     } 
     return val; 
    } 
} 

(ध्यान दें मैं खुशी से लोगों का तर्क होता है कि उस ReturnInside एक सरल/सी # के क्लीनर सा है)

और (IL को देखो रिलीज़ मोड आदि):

.method private hidebysig static int32 ReturnInside() cil managed 
{ 
    .maxstack 2 
    .locals init (
     [0] int32 CS$1$0000, 
     [1] object CS$2$0001) 
    L_0000: ldsfld object Program::sync 
    L_0005: dup 
    L_0006: stloc.1 
    L_0007: call void [mscorlib]System.Threading.Monitor::Enter(object) 
    L_000c: call int32 Program::GetValue() 
    L_0011: stloc.0 
    L_0012: leave.s L_001b 
    L_0014: ldloc.1 
    L_0015: call void [mscorlib]System.Threading.Monitor::Exit(object) 
    L_001a: endfinally 
    L_001b: ldloc.0 
    L_001c: ret 
    .try L_000c to L_0014 finally handler L_0014 to L_001b 
} 

method private hidebysig static int32 ReturnOutside() cil managed 
{ 
    .maxstack 2 
    .locals init (
     [0] int32 val, 
     [1] object CS$2$0000) 
    L_0000: ldsfld object Program::sync 
    L_0005: dup 
    L_0006: stloc.1 
    L_0007: call void [mscorlib]System.Threading.Monitor::Enter(object) 
    L_000c: call int32 Program::GetValue() 
    L_0011: stloc.0 
    L_0012: leave.s L_001b 
    L_0014: ldloc.1 
    L_0015: call void [mscorlib]System.Threading.Monitor::Exit(object) 
    L_001a: endfinally 
    L_001b: ldloc.0 
    L_001c: ret 
    .try L_000c to L_0014 finally handler L_0014 to L_001b 
} 

तो आईएल स्तर वे कर रहे हैं पर [दे या कुछ नाम ले] समान (मैं कुछ ;-p) सीखा है। इस तरह, एकमात्र समझदार तुलना स्थानीय कोडिंग शैली का (अत्यधिक व्यक्तिपरक) कानून है ... मैं सादगी के लिए ReturnInside पसंद करता हूं, लेकिन मैं इसके बारे में उत्साहित नहीं होगा।

Answer 2

इससे कोई फर्क नहीं पड़ता; वे दोनों संकलक द्वारा एक ही चीज़ में अनुवादित हैं।

स्पष्ट करने के लिए, या तो प्रभावी रूप से निम्नलिखित अर्थ विज्ञान के साथ कुछ करने के लिए अनुवाद किया है:

T myData; 
Monitor.Enter(mutex) 
try 
{ 
    myData= // something 
} 
finally 
{ 
    Monitor.Exit(mutex); 
} 

return myData; 

Answer 3

बाहर क्लीनर लग रहा है।

Answer 4

साथी डेवलपर्स के कोड को पढ़ने में आसान बनाने के लिए मैं पहला विकल्प सुझाऊंगा।

Answer 5

तो लगता है कि ताला बाहर बेहतर लग रहा है, लेकिन सावधान यदि आप करने के लिए कोड को बदलने अंत हो:

return f(...) 

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

Answer 6

यह निर्भर करता है,

मैं यहाँ अनाज के खिलाफ जाने के लिए जा रहा हूँ। मैं आम तौर पर ताला के अंदर वापस आऊंगा।

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

तो आपकी तुलना वास्तव में त्रुटिपूर्ण है। जबकि आदर्श रूप से दोनों विकल्पों के बीच का अंतर आपके जैसा लिखा गया होगा, जो प्रतीत होता है कि यह मामला 1 मामला है, प्रैक्टिस में यह थोड़ा उलझन में है।

void example() { 
    int myData; 
    lock (foo) { 
     myData = ...; 
    } 
    return myData 
} 

बनाम

void example() { 
    lock (foo) { 
     return ...; 
    } 
} 

मैं मामले 2 विशेष रूप से छोटे-छोटे स्निपेट के लिए पेंच को पढ़ने के लिए काफी आसान है और कठिन हो सकता है, लगता है।

Answer 7

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

Answer 8

इसके लायक होने के लिए, documentation on MSDN में लॉक के अंदर से लौटने का एक उदाहरण है। यहां पर दिए गए अन्य उत्तरों से, यह बहुत समान आईएल प्रतीत होता है, लेकिन मेरे लिए, यह लॉक के अंदर से वापस लौटने के लिए सुरक्षित लगता है क्योंकि तब आप किसी अन्य थ्रेड द्वारा ओवरराइट किए जाने वाले रिटर्न वैरिएबल का जोखिम नहीं चलाते हैं। हमेशा

Answer 9

lock() return <expression> बयान:

1) ताला

2) निर्दिष्ट प्रकार के मूल्य के लिए बनाता है स्थानीय (धागा सुरक्षित) स्टोर में प्रवेश करेंगे,

3) मूल्य के साथ दुकान भरता है <expression> द्वारा दिया,

4) से बाहर निकलें ताला

5) की दुकान वापस जाएँ।

इसका मतलब है कि लॉक स्टेटमेंट से लौटाया गया मूल्य, हमेशा लौटने से पहले "पकाया जाता है"।

lock() return के बारे में चिंता मत करो, यहाँ किसी को भी सुन नहीं है))