Mã này bị treo ở chế độ phát hành nhưng hoạt động tốt ở chế độ gỡ lỗi

Tôi đã xem qua điều này và muốn biết lý do của hành vi này trong chế độ gỡ lỗi và phát hành.

public static void Main(string[] args)
{            
   bool isComplete = false;

   var t = new Thread(() =>
   {
       int i = 0;

        while (!isComplete) i += 0;
   });

   t.Start();

   Thread.Sleep(500);
   isComplete = true;
   t.Join();
   Console.WriteLine("complete!");
}

Tôi đoán rằng trình tối ưu hóa bị đánh lừa bởi thiếu từ khóa 'dễ bay hơi' trên isCompletebiến.

Tất nhiên, bạn không thể thêm nó, vì nó là một biến cục bộ. Và tất nhiên, vì nó là một biến cục bộ, nó không cần thiết chút nào, bởi vì các biến địa phương được lưu giữ trên chồng và chúng đương nhiên luôn "tươi".

Tuy nhiên , sau khi biên dịch, nó không còn là một biến cục bộ nữa. Vì nó được truy cập trong một đại biểu ẩn danh, mã được tách và nó được dịch thành một lớp trợ giúp và trường thành viên, giống như:

public static void Main(string[] args)
{
    TheHelper hlp = new TheHelper();

    var t = new Thread(hlp.Body);

    t.Start();

    Thread.Sleep(500);
    hlp.isComplete = true;
    t.Join();
    Console.WriteLine("complete!");
}

private class TheHelper
{
    public bool isComplete = false;

    public void Body()
    {
        int i = 0;

        while (!isComplete) i += 0;
    }
}

Bây giờ tôi có thể tưởng tượng rằng trình biên dịch / tối ưu hóa JIT trong môi trường đa luồng, khi xử lý TheHelperlớp, thực sự có thể lưu giá trị falsevào bộ nhớ cache trong một số thanh ghi hoặc khung ngăn xếp ở đầu Body()phương thức và không bao giờ làm mới nó cho đến khi phương thức kết thúc. Đó là bởi vì KHÔNG CÓ ĐẢM BẢO rằng luồng & phương thức sẽ KHÔNG kết thúc trước khi "= true" được thực thi, vì vậy nếu không có gì đảm bảo, thì tại sao không lưu vào bộ nhớ cache và tăng hiệu suất đọc đối tượng heap một lần thay vì đọc nó mọi lúc sự lặp lại.

Đây chính là lý do tại sao từ khóa volatiletồn tại.

Để lớp trợ giúp này chính xác tốt hơn một chút ¹⁾ trong môi trường đa luồng, nó phải có:

    public volatile bool isComplete = false;

nhưng, tất nhiên, vì nó là mã được tạo tự động, bạn không thể thêm nó. Một cách tiếp cận tốt hơn sẽ là thêm một số lock()s xung quanh việc đọc và ghi isCompleted, hoặc sử dụng một số tiện ích đồng bộ hóa / phân luồng / tác vụ sẵn sàng sử dụng khác thay vì cố gắng làm điều đó bằng kim loại trần (mà nó sẽ không phải là kim loại trần, vì nó là C # trên CLR với GC, JIT và (..)).

Sự khác biệt trong chế độ gỡ lỗi xảy ra có thể là do trong chế độ gỡ lỗi, nhiều tính năng tối ưu bị loại trừ, vì vậy bạn có thể gỡ lỗi mã mà bạn thấy trên màn hình. Do đó while (!isComplete)không được tối ưu hóa để bạn có thể đặt một điểm ngắt ở đó và do đó isCompletekhông được lưu trữ tích cực trong một thanh ghi hoặc ngăn xếp khi bắt đầu phương thức và được đọc từ đối tượng trên heap ở mỗi lần lặp vòng lặp.

BTW. Đó chỉ là suy đoán của tôi về điều đó. Tôi thậm chí đã không cố gắng biên dịch nó.

BTW. Nó dường như không phải là một lỗi; nó giống như một tác dụng phụ rất khó hiểu. Ngoài ra, nếu tôi nói đúng về nó, thì đó có thể là một sự thiếu sót về ngôn ngữ - C # nên cho phép đặt từ khóa 'variable' trên các biến cục bộ được nắm bắt và thăng cấp cho các trường thành viên trong phần đóng.

¹⁾ xem bên dưới để biết nhận xét từ Eric Lippert về volatilevà / hoặc bài viết rất thú vị này cho thấy mức độ phức tạp liên quan đến việc đảm bảo rằng mã dựa vào volatilelà an toàn ..uh, tốt ..uh, hãy nói OK.

Câu trả lời của quetzalcoatl là đúng. Để làm sáng tỏ hơn về nó:

Trình biên dịch C # và CLR jitter được phép thực hiện nhiều tối ưu hóa tuyệt vời giả định rằng luồng hiện tại là luồng duy nhất đang chạy. Nếu những tối ưu hóa đó làm cho chương trình không chính xác trong một thế giới mà luồng hiện tại không phải là luồng duy nhất đang chạy thì đó là vấn đề của bạn . Bạn được yêu cầu viết các chương trình đa luồng cho trình biên dịch và jitter biết bạn đang làm những thứ đa luồng điên rồ nào.

Trong trường hợp cụ thể này, jitter được phép - nhưng không bắt buộc - quan sát rằng biến không thay đổi bởi thân vòng lặp và do đó kết luận rằng - vì theo giả định đây là luồng duy nhất đang chạy - biến sẽ không bao giờ thay đổi. Nếu nó không bao giờ thay đổi thì biến cần được kiểm tra sự thật một lần , không phải mỗi lần qua vòng lặp. Và đây là thực tế những gì đang xảy ra.

Làm thế nào để giải quyết điều này? Không viết các chương trình đa luồng . Đa luồng rất khó để thực hiện đúng, ngay cả đối với các chuyên gia. Nếu bạn phải, thì hãy sử dụng các cơ chế cấp cao nhất để đạt được mục tiêu của bạn . Giải pháp ở đây là không làm cho biến số dễ bay hơi. Giải pháp ở đây là viết một tác vụ có thể hủy và sử dụng cơ chế hủy bỏ Thư viện song song Tác vụ . Hãy để TPL lo lắng về việc nhận đúng logic luồng và việc hủy gửi đúng cách giữa các luồng.

Tôi đã gắn liền với quá trình chạy và nhận thấy (nếu tôi không mắc lỗi, tôi không thực hành nhiều với điều này) rằng Threadphương pháp được dịch thành như sau:

debug051:02DE04EB loc_2DE04EB:                            
debug051:02DE04EB test    eax, eax
debug051:02DE04ED jz      short loc_2DE04EB
debug051:02DE04EF pop     ebp
debug051:02DE04F0 retn

eax(chứa giá trị của isComplete) được tải lần đầu tiên và không bao giờ được làm mới.

Không thực sự là một câu trả lời, nhưng để làm sáng tỏ thêm một số vấn đề:

Vấn đề dường như là khi nào iđược khai báo bên trong thân lambda và nó chỉ được đọc trong biểu thức gán. Nếu không, mã hoạt động tốt ở chế độ phát hành:

1. i được khai báo bên ngoài thân lambda:

   int i = 0; // Declared outside the lambda body
   
   var t = new Thread(() =>
   {
       while (!isComplete) { i += 0; }
   }); // Completes in release mode

2. i không được đọc trong biểu thức gán:

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { i = 0; }
   }); // Completes in release mode

3. i cũng được đọc ở một nơi khác:

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { Console.WriteLine(i); i += 0; }
   }); // Completes in release mode

Cá cược của tôi là một số trình biên dịch hoặc tối ưu hóa JIT liên quan đến việc ilàm rối tung mọi thứ. Ai đó thông minh hơn tôi có thể sẽ có thể làm sáng tỏ vấn đề này.

Tuy nhiên, tôi sẽ không lo lắng quá nhiều về điều đó, bởi vì tôi không biết mã tương tự sẽ thực sự phục vụ cho mục đích nào.