Một tuyên bố trở lại nên được bên trong hoặc bên ngoài một khóa?

Tôi chỉ nhận ra rằng ở một nơi nào đó trong mã của tôi, tôi có câu lệnh return bên trong khóa và đôi khi ở bên ngoài. Cái nào là tốt nhất?

1)

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

2)

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

}

Tôi nên sử dụng cái nào?

Về cơ bản, điều này bao giờ làm cho mã đơn giản hơn. Một điểm thoát duy nhất là một lý tưởng tốt đẹp, nhưng tôi sẽ không bẻ cong mã ra khỏi hình dạng chỉ để đạt được nó ... Và nếu phương án thay thế là khai báo một biến cục bộ (bên ngoài khóa), hãy khởi tạo nó (bên trong khóa) và sau đó trả lại (bên ngoài khóa), sau đó tôi sẽ nói rằng một "return foo" đơn giản bên trong khóa đơn giản hơn rất nhiều.

Để hiển thị sự khác biệt trong IL, hãy cho phép mã:

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

(lưu ý rằng tôi vui vẻ tranh luận rằng đó ReturnInsidelà một bit đơn giản / gọn gàng hơn của C #)

Và nhìn vào IL (chế độ phát hành, v.v.):

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

Vì vậy, ở cấp độ IL, chúng giống nhau [cho hoặc lấy một số tên] (tôi đã học được điều gì đó ;-p). Như vậy, so sánh hợp lý duy nhất là luật (rất chủ quan) của phong cách mã hóa địa phương ... Tôi thích ReturnInsidesự đơn giản, nhưng tôi cũng không hào hứng với điều đó.

Nó không làm cho bất kỳ sự khác biệt; cả hai đều được dịch sang cùng một thứ bởi trình biên dịch.

Để làm rõ, một trong hai được dịch một cách hiệu quả với một ngữ nghĩa sau:

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

return myData;

Tôi chắc chắn sẽ đặt sự trở lại bên trong khóa. Nếu không, bạn có nguy cơ một luồng khác nhập khóa và sửa đổi biến của bạn trước câu lệnh return, do đó làm cho người gọi ban đầu nhận được một giá trị khác so với dự kiến.

Nó phụ thuộc

Tôi sẽ đi ngược lại hạt lúa ở đây. Tôi thường sẽ trở lại bên trong khóa.

Thông thường biến mydata là một biến cục bộ. Tôi thích khai báo các biến cục bộ trong khi tôi khởi tạo chúng. Tôi hiếm khi có dữ liệu để khởi tạo giá trị trả lại của mình bên ngoài khóa.

Vì vậy, so sánh của bạn là thực sự thiếu sót. Mặc dù lý tưởng là sự khác biệt giữa hai tùy chọn sẽ như bạn đã viết, dường như đưa ra cái gật đầu cho trường hợp 1, trong thực tế, nó hơi xấu hơn một chút.

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

so với

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

Tôi thấy trường hợp 2 dễ đọc hơn và khó bắt vít hơn, đặc biệt là đối với các đoạn ngắn.

Nếu nghĩ rằng khóa bên ngoài có vẻ tốt hơn, nhưng hãy cẩn thận nếu bạn cuối cùng thay đổi mã thành:

return f(...)

Nếu f () cần được gọi với khóa được giữ thì rõ ràng nó cần phải ở bên trong khóa, vì việc giữ lại trả lại bên trong khóa để đảm bảo tính nhất quán.

Đối với giá trị của nó, tài liệu về MSDN có một ví dụ về việc quay lại từ bên trong khóa. Từ các câu trả lời khác ở đây, có vẻ như IL khá giống nhau, nhưng đối với tôi, việc quay trở lại từ bên trong khóa có vẻ an toàn hơn vì sau đó bạn không có nguy cơ biến trả về bị ghi đè bởi một luồng khác.

Để giúp các nhà phát triển đồng nghiệp đọc mã dễ dàng hơn, tôi sẽ đề xuất phương án đầu tiên.

lock() return <expression> báo cáo luôn:

1) nhập khóa

2) lưu trữ cục bộ (an toàn luồng) cho giá trị của loại đã chỉ định,

3) lấp đầy cửa hàng với giá trị được trả về bởi <expression>,

4) khóa thoát

5) trả lại cửa hàng.

Nó có nghĩa là giá trị đó, được trả về từ câu lệnh khóa, luôn được "nấu chín" trước khi trả về.

Đừng lo lắng lock() return, đừng nghe ai ở đây))

^{Lưu ý: Tôi tin rằng câu trả lời này là chính xác và tôi hy vọng rằng nó cũng hữu ích, nhưng tôi luôn vui lòng cải thiện nó dựa trên phản hồi cụ thể.}

Để tóm tắt và bổ sung cho các câu trả lời hiện có:

• Các câu trả lời được chấp nhận cho thấy, không phân biệt trong đó cú pháp mẫu bạn chọn trong của bạn # C mã, trong các mã IL - và do đó trong thời gian chạy - những returnkhông xảy ra cho đến khi sau khi khóa được phát hành.

  • Mặc dù đặt return bên trong các lockkhối do đó, Nghiêm nói, trình bày sai dòng điều khiển ^[1] , nó là cú pháp thuận tiện ở chỗ nó obviates sự cần thiết để lưu trữ giá trị trả về trong một aux. biến cục bộ (được khai báo bên ngoài khối, để nó có thể được sử dụng với returnbên ngoài khối) - xem câu trả lời của Edward KMETT .

• Một cách riêng biệt - và khía cạnh này là ngẫu nhiên cho câu hỏi, nhưng vẫn có thể được quan tâm ( câu trả lời của Ricardo Villamil cố gắng giải quyết nó, nhưng tôi nghĩ không chính xác) - kết hợp một locktuyên bố với một returntuyên bố - tức là, đạt được giá trị returntrong một khối được bảo vệ khỏi một khối truy cập đồng thời - chỉ có ý nghĩa "bảo vệ" giá trị được trả về trong phạm vi của người gọi nếu nó không thực sự cần bảo vệ một khi có được , áp dụng trong các trường hợp sau:

  • Nếu giá trị được trả về là một phần tử từ bộ sưu tập chỉ cần bảo vệ về mặt thêm và xóa phần tử, không phải về mặt sửa đổi của chính các phần tử và / hoặc ...

  • ... nếu giá trị được trả về là một thể hiện của loại giá trị hoặc chuỗi .

    • Lưu ý rằng trong trường hợp này, người gọi nhận được một ảnh chụp nhanh (bản sao) ^[2] của giá trị - mà tại thời điểm người gọi kiểm tra, nó có thể không còn là giá trị hiện tại trong cấu trúc dữ liệu gốc.

  • Trong mọi trường hợp khác, việc khóa phải được thực hiện bởi người gọi , không phải (chỉ) bên trong phương thức.

^{[1] Theodor Zoulias chỉ ra rằng đó là về mặt kỹ thuật cũng đúng đối với việc đặt returnbên trong try, catch, using, if, while, for, ... báo cáo; tuy nhiên, mục đích cụ thể của locktuyên bố có khả năng mời xem xét kỹ lưỡng luồng kiểm soát thực sự, bằng chứng là câu hỏi này đã được hỏi và nhận được nhiều sự chú ý.}

^{[2] Truy cập một thể hiện kiểu giá trị luôn tạo ra một bản sao luồng cục bộ, trên ngăn xếp của nó; mặc dù các chuỗi là các thể hiện kiểu tham chiếu kỹ thuật, chúng hoạt động hiệu quả với các thể hiện kiểu giá trị.}