Tại sao std :: nguyên tử <T> :: is_lock_free () không tĩnh cũng như constexpr?

Bất cứ ai có thể cho tôi biết liệu std :: atomic :: is_lock_free () không tĩnh cũng như constexpr? Có nó không tĩnh và / hoặc không phải là constexpr không có ý nghĩa đối với tôi.

Như đã giải thích về cppreference :

Tất cả các loại nguyên tử ngoại trừ std :: atomic_flag có thể được thực hiện bằng cách sử dụng mutexes hoặc các hoạt động khóa khác, thay vì sử dụng các hướng dẫn CPU nguyên tử không khóa. Các loại nguyên tử đôi khi cũng được phép không có khóa, ví dụ: nếu chỉ các truy cập bộ nhớ được căn chỉnh là nguyên tử tự nhiên trên một kiến ​​trúc nhất định, các đối tượng sai lệch cùng loại phải sử dụng khóa.

Tiêu chuẩn C ++ khuyến nghị (nhưng không yêu cầu) rằng các hoạt động nguyên tử không khóa cũng không có địa chỉ, nghĩa là phù hợp để liên lạc giữa các quá trình sử dụng bộ nhớ dùng chung.

Như được đề cập bởi nhiều người khác, std::is_always_lock_freecó thể là những gì bạn đang thực sự tìm kiếm.

Chỉnh sửa: Để làm rõ, các loại đối tượng C ++ có giá trị căn chỉnh giới hạn địa chỉ của các thể hiện của chúng chỉ ở bội số quyền hạn nhất định của hai ( [basic.align]). Các giá trị căn chỉnh này được xác định theo thực hiện cho các loại cơ bản và không cần bằng kích thước của loại. Họ cũng có thể nghiêm ngặt hơn những gì phần cứng thực sự có thể hỗ trợ.

Ví dụ: x86 (hầu hết) hỗ trợ truy cập không được phân bổ. Tuy nhiên, bạn sẽ tìm thấy hầu hết các trình biên dịch có alignof(double) == sizeof(double) == 8x86, vì các truy cập không được sắp xếp có một loạt các nhược điểm (tốc độ, bộ đệm, nguyên tử ...). Nhưng ví dụ #pragma pack(1) struct X { char a; double b; };hoặc alignas(1) double x;cho phép bạn có "không được phân bổ" double. Vì vậy, khi cppreference nói về "truy cập bộ nhớ được căn chỉnh", có lẽ nó làm như vậy về mặt căn chỉnh tự nhiên của loại cho phần cứng, không sử dụng loại C ++ theo cách trái ngược với yêu cầu căn chỉnh của nó (sẽ là UB).

Dưới đây là thông tin thêm: Hiệu ứng thực tế của các truy cập không được phân bổ thành công trên x86 là gì?

Vui lòng kiểm tra các bình luận sâu sắc của @Peter Cordes bên dưới!

Bạn có thể sử dụng std::is_always_lock_free

is_lock_free phụ thuộc vào hệ thống thực tế và không thể được xác định tại thời điểm biên dịch.

Giải thích có liên quan:

Các loại nguyên tử đôi khi cũng được phép không có khóa, ví dụ: nếu chỉ các truy cập bộ nhớ được căn chỉnh là nguyên tử tự nhiên trên một kiến ​​trúc nhất định, các đối tượng sai lệch cùng loại phải sử dụng khóa.

Tôi đã cài đặt Visual Studio 2019 trên Windows-PC của mình và devenv này cũng có trình biên dịch ARMv8. ARMv8 cho phép truy cập không được phân bổ, nhưng so sánh và hoán đổi, bổ sung bị khóa, v.v ... bắt buộc phải được căn chỉnh. Và cả tải thuần / cửa hàng thuần túy sử dụng ldphoặc stp(cặp tải hoặc cặp thanh ghi 32 bit) chỉ được đảm bảo là nguyên tử khi chúng được căn chỉnh tự nhiên.

Vì vậy, tôi đã viết một chương trình nhỏ để kiểm tra những gì is_lock_free () trả về cho một con trỏ nguyên tử tùy ý. Vì vậy, đây là mã:

#include <atomic>
#include <cstddef>

using namespace std;

bool isLockFreeAtomic( atomic<uint64_t> *a64 )
{
    return a64->is_lock_free();
}

Và đây là sự phân tách của isLockFreeAtomic

|?isLockFreeAtomic@@YA_NPAU?$atomic@_K@std@@@Z| PROC
    movs        r0,#1
    bx          lr
ENDP

Đây chỉ là returns true, aka 1.

Việc thực hiện này chọn sử dụng alignof( atomic<int64_t> ) == 8để mọi thứ atomic<int64_t>được căn chỉnh chính xác. Điều này tránh sự cần thiết phải kiểm tra căn chỉnh thời gian chạy trên mỗi tải và lưu trữ.

(Lưu ý của biên tập viên: điều này là phổ biến; hầu hết các triển khai C ++ ngoài đời thực đều hoạt động theo cách này. Đây là lý do tại sao std::is_always_lock_freerất hữu ích: bởi vì nó thường đúng với các loại is_lock_free()đã từng đúng.)