Chương trình đa luồng bị kẹt trong chế độ tối ưu hóa nhưng chạy bình thường trong -O0

Tôi đã viết một chương trình đa luồng đơn giản như sau:

static bool finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Nó hoạt động bình thường trong chế độ gỡ lỗi trong Visual studio hoặc -O0trong gc c và in ra kết quả sau 1vài giây. Nhưng nó bị kẹt và không in bất cứ điều gì trong chế độ Phát hành hoặc -O1 -O2 -O3.

Hai luồng, truy cập vào một biến không nguyên tử, không được bảo vệ là UB Mối quan tâm này finished. Bạn có thể làm cho finishedloại std::atomic<bool>để sửa lỗi này.

Sửa chữa của tôi:

#include <iostream>
#include <future>
#include <atomic>

static std::atomic<bool> finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Đầu ra:

result =1023045342
main thread id=140147660588864

Demo trực tiếp trên coliru

Ai đó có thể nghĩ 'Đó là một bool- có thể là một chút. Làm thế nào điều này có thể là phi nguyên tử? ' (Tôi đã làm khi tôi bắt đầu với đa luồng.)

Nhưng lưu ý rằng việc thiếu nước mắt không phải là điều duy nhất std::atomicmang lại cho bạn. Nó cũng làm cho truy cập đọc + ghi đồng thời từ nhiều luồng được xác định rõ, ngăn trình biên dịch giả định rằng đọc lại biến sẽ luôn thấy cùng một giá trị.

Làm cho một người boolkhông được bảo vệ, không nguyên tử có thể gây ra các vấn đề bổ sung:

• Trình biên dịch có thể quyết định tối ưu hóa biến thành một thanh ghi hoặc thậm chí nhiều CSE truy cập vào một và kéo tải ra khỏi một vòng lặp.
• Biến có thể được lưu trữ cho lõi CPU. (Trong cuộc sống thực, CPU có bộ nhớ kết hợp . Đây không phải là vấn đề thực sự, nhưng tiêu chuẩn C ++ đủ lỏng để bao gồm các triển khai C ++ giả định trên bộ nhớ chia sẻ không kết hợp trong đó atomic<bool>vớimemory_order_relaxed cửa hàng / tải sẽ làm việc, nhưng mà volatilesẽ không được. Sử dụng không ổn định cho điều này sẽ là UB, mặc dù nó hoạt động trên thực tế trên các triển khai C ++ thực sự.)

Để ngăn chặn điều này xảy ra, trình biên dịch phải được thông báo rõ ràng không làm.

Tôi hơi ngạc nhiên về cuộc thảo luận đang phát triển liên quan đến mối quan hệ tiềm năng của volatile vấn đề này. Vì vậy, tôi muốn tiêu hai xu của mình:

• Là dễ bay hơi hữu ích với chủ đề
• Ai sợ một trình biên dịch tối ưu hóa xấu lớn? .

Câu trả lời của Scheff mô tả cách sửa mã của bạn. Tôi nghĩ rằng tôi sẽ thêm một chút thông tin về những gì đang thực sự xảy ra trong trường hợp này.

Tôi đã biên dịch mã của bạn tại godbolt bằng cách sử dụng tối ưu hóa mức 1 ( -O1). Hàm của bạn biên dịch như vậy:

func():
  cmp BYTE PTR finished[rip], 0
  jne .L4
.L5:
  jmp .L5
.L4:
  mov eax, 0
  ret

Vậy thì chuyện gì đã xảy ra ở đây? Đầu tiên, chúng tôi có một so sánh: cmp BYTE PTR finished[rip], 0- kiểm tra này để xem liệu finishedcó sai hay không.

Nếu nó không sai (aka đúng), chúng ta nên thoát khỏi vòng lặp trong lần chạy đầu tiên. Đây thực hiện bằng cách jne .L4đó j umps khi n ot e qual để nhãn .L4trong đó giá trị của i( 0) được lưu trữ trong một thanh ghi để sử dụng sau và trở về chức năng.

Nếu đó là sai, tuy nhiên, chúng tôi chuyển đến

.L5:
  jmp .L5

Đây là một bước nhảy vô điều kiện, để gắn nhãn .L5mà chính là lệnh nhảy.

Nói cách khác, chuỗi được đưa vào một vòng lặp bận rộn vô hạn.

Vậy tại sao điều này đã xảy ra?

Theo như trình tối ưu hóa có liên quan, các chủ đề nằm ngoài phạm vi của nó. Nó giả định các luồng khác không đọc hoặc ghi các biến đồng thời (vì đó sẽ là cuộc đua dữ liệu UB). Bạn cần nói với nó rằng nó không thể tối ưu hóa truy cập đi. Đây là lúc câu trả lời của Scheff đến. Tôi sẽ không nhắc lại anh ta.

Bởi vì trình tối ưu hóa không được thông báo rằng finishedbiến có thể có khả năng thay đổi trong quá trình thực thi hàm, nó thấy rằng finishednó không bị sửa đổi bởi chính hàm đó và cho rằng nó là hằng số.

Mã được tối ưu hóa cung cấp hai đường dẫn mã sẽ dẫn đến việc nhập hàm với giá trị bool không đổi; hoặc nó chạy vòng lặp vô hạn, hoặc vòng lặp không bao giờ chạy.

tại -O0trình biên dịch (như mong đợi) không tối ưu hóa thân vòng lặp và so sánh đi:

func():
  push rbp
  mov rbp, rsp
  mov QWORD PTR [rbp-8], 0
.L148:
  movzx eax, BYTE PTR finished[rip]
  test al, al
  jne .L147
  add QWORD PTR [rbp-8], 1
  jmp .L148
.L147:
  mov rax, QWORD PTR [rbp-8]
  pop rbp
  ret

do đó, chức năng, khi không được tối ưu hóa hoạt động, việc thiếu tính nguyên tử ở đây thường không phải là vấn đề, bởi vì mã và kiểu dữ liệu là đơn giản. Có lẽ điều tồi tệ nhất chúng ta có thể gặp phải ở đây là giá trị của inó bị giảm đi so với những gì nó nên có.

Một hệ thống phức tạp hơn với cấu trúc dữ liệu có nhiều khả năng dẫn đến dữ liệu bị hỏng hoặc thực thi không đúng.

Vì lợi ích của sự hoàn thiện trong đường cong học tập; bạn nên tránh sử dụng các biến toàn cục. Bạn đã làm một công việc tốt mặc dù bằng cách làm cho nó tĩnh, vì vậy nó sẽ là cục bộ cho đơn vị dịch thuật.

Đây là một ví dụ:

class ST {
public:
    int func()
    {
        size_t i = 0;
        while (!finished)
            ++i;
        return i;
    }
    void setFinished(bool val)
    {
        finished = val;
    }
private:
    std::atomic<bool> finished = false;
};

int main()
{
    ST st;
    auto result=std::async(std::launch::async, &ST::func, std::ref(st));
    std::this_thread::sleep_for(std::chrono::seconds(1));
    st.setFinished(true);
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Sống trên Wandbox