Haruskah pernyataan kembali berada di dalam atau di luar kunci?

Saya baru menyadari bahwa di suatu tempat dalam kode saya, saya memiliki pernyataan pengembalian di dalam kunci dan kadang di luar. Yang mana yang terbaik?

1)

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

2)

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

}

Yang mana yang harus saya gunakan?

Intinya, mana yang pernah membuat kode lebih sederhana. Satu titik keluar adalah ideal yang bagus, tapi saya tidak akan membengkokkan kode keluar dari bentuk hanya untuk mencapainya ... Dan jika alternatifnya mendeklarasikan variabel lokal (di luar kunci), menginisialisasi (di dalam kunci) dan lalu mengembalikannya (di luar kunci), maka saya akan mengatakan bahwa "pengembalian foo" sederhana di dalam kunci jauh lebih sederhana.

Untuk menunjukkan perbedaan dalam IL, mari kode:

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;
    }
}

(perhatikan bahwa saya akan dengan senang hati berpendapat bahwa itu ReturnInsideadalah sedikit lebih mudah / bersih dari C #)

Dan lihat IL (mode rilis dll):

.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
}

Jadi pada level IL, mereka [memberi atau menerima beberapa nama] identik (saya belajar sesuatu ;-p). Dengan demikian, satu-satunya perbandingan yang masuk akal adalah hukum (sangat subyektif) gaya pengkodean lokal ... Saya lebih suka ReturnInsideuntuk kesederhanaan, tapi saya tidak akan senang dengan baik.

Tidak ada bedanya; keduanya diterjemahkan ke hal yang sama oleh kompiler.

Untuk memperjelas, keduanya diterjemahkan secara efektif ke sesuatu dengan semantik berikut:

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

return myData;

Saya pasti akan memasukkan pengembalian di dalam kunci. Kalau tidak, Anda berisiko untaian lain memasuki kunci dan memodifikasi variabel Anda sebelum pernyataan kembali, sehingga membuat penelepon asli menerima nilai yang berbeda dari yang diharapkan.

Tergantung,

Saya akan menentang gandum di sini. Saya biasanya akan kembali ke dalam kunci.

Biasanya variabel mydata adalah variabel lokal. Saya suka mendeklarasikan variabel lokal saat saya menginisialisasi mereka. Saya jarang memiliki data untuk menginisialisasi nilai saya di luar kunci saya.

Jadi perbandingan Anda sebenarnya cacat. Meskipun idealnya perbedaan antara dua opsi akan seperti yang Anda tulis, yang tampaknya memberi anggukan pada kasus 1, dalam praktiknya sedikit lebih jelek.

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

vs.

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

Saya menemukan case 2 lebih mudah dibaca dan lebih sulit untuk dikacaukan, terutama untuk cuplikan singkat.

Jika mengira kunci di luar terlihat lebih baik, tetapi berhati-hatilah jika Anda akhirnya mengubah kode menjadi:

return f(...)

Jika f () perlu dipanggil dengan kunci dipegang maka jelas perlu di dalam kunci, karena itu menjaga kembali di dalam kunci untuk konsistensi masuk akal.

Untuk apa nilainya, dokumentasi pada MSDN memiliki contoh untuk kembali dari dalam kunci. Dari jawaban lain di sini, tampaknya IL yang sangat mirip tetapi, bagi saya, itu tampak lebih aman untuk kembali dari dalam kunci karena dengan begitu Anda tidak menjalankan risiko variabel pengembalian ditimpa oleh utas lainnya.

Untuk membuatnya lebih mudah bagi sesama pengembang untuk membaca kode saya akan menyarankan alternatif pertama.

lock() return <expression> pernyataan selalu:

1) masukkan kunci

2) membuat toko lokal (aman-thread) untuk nilai dari jenis yang ditentukan,

3) mengisi toko dengan nilai yang dikembalikan oleh <expression>,

4) kunci keluar

5) mengembalikan toko.

Ini berarti bahwa nilai, yang dikembalikan dari pernyataan kunci, selalu "dimasak" sebelum kembali.

Jangan khawatir lock() return, jangan dengarkan siapa pun di sini))

^{Catatan: Saya yakin jawaban ini benar secara faktual dan saya harap ini membantu juga, tapi saya selalu senang memperbaikinya berdasarkan umpan balik yang konkret.}

Untuk merangkum dan melengkapi jawaban yang ada:

• The diterima jawaban menunjukkan bahwa, terlepas dari yang bentuk sintaks yang Anda pilih dalam Anda # C kode, dalam kode IL - dan karena itu pada saat runtime - yang returntidak terjadi sampai setelah mengunci dilepaskan.

  • Meskipun menempatkan return dalam satu lockblok Oleh karena itu, tegasnya, salah mengartikan aliran kontrol ^[1] , itu adalah sintaksis nyaman dalam hal itu menyingkirkan kebutuhan untuk menyimpan nilai kembali dalam aux. variabel lokal (dideklarasikan di luar blok, sehingga dapat digunakan dengan di returnluar blok) - lihat jawaban Edward KMETT .

• Secara terpisah - dan aspek ini insidental untuk pertanyaan, tetapi mungkin masih menarik ( jawaban Ricardo Villamil mencoba mengatasinya, tetapi saya kira salah) - menggabungkan lockpernyataan dengan returnpernyataan - yaitu, mendapatkan nilai returndalam blok yang dilindungi dari akses bersamaan - hanya bermakna "melindungi" nilai yang dikembalikan dalam ruang lingkup penelepon jika sebenarnya tidak perlu dilindungi setelah diperoleh , yang berlaku dalam skenario berikut:

  • Jika nilai yang dikembalikan adalah elemen dari koleksi yang hanya perlu perlindungan dalam hal menambah dan menghapus elemen, tidak dalam hal modifikasi dari elemen itu sendiri dan / atau ...

  • ... jika nilai yang dikembalikan adalah turunan dari tipe nilai atau string .

    • Perhatikan bahwa dalam hal ini pemanggil menerima snapshot (copy) ^[2] dari nilai - yang pada saat pemanggil memeriksa tidak lagi mungkin nilai saat ini dalam struktur data asal.

  • Dalam kasus lain, penguncian harus dilakukan oleh pemanggil , bukan (hanya) di dalam metode.

^{[1] Theodor Zoulias menunjukkan bahwa itu secara teknis juga berlaku untuk penempatan returndi dalam try,catch , using, if, while, for, ... pernyataan; Namun, itu adalah tujuan khusus dari lockpernyataan yang cenderung mengundang pengawasan aliran kontrol yang sebenarnya, sebagaimana dibuktikan oleh pertanyaan ini yang telah ditanyakan dan telah menerima banyak perhatian.}

^{[2] Mengakses contoh tipe nilai selalu menciptakan salinan thread-local, on-the-stack; walaupun string secara teknis adalah tipe instance, mereka secara efektif berperilaku seperti-nilai tipe.}