Чому std :: atomic <T> :: is_lock_free () не є статичним, а також constexpr?

Хто-небудь може сказати мені, чи std :: atomic :: is_lock_free () не є статичним, а також constexpr? Наявність його нестатичного та / або як non-constexpr для мене не має сенсу.

Як пояснено на cppreference :

Усі типи атомів, за винятком std :: atomic_flag, можуть бути реалізовані за допомогою мутексів або інших операцій блокування, а не з використанням атомних інструкцій щодо блокування атомних процесорів. Атомні типи також можуть бути іноді без замків, наприклад, якщо для заданої архітектури лише вирівняні пам’яті пам’яті природно є атомними, нерівні об’єкти одного типу повинні використовувати блоки.

Стандарт C ++ рекомендує (але не вимагає), щоб атомні операції без блокування були також без адреси, тобто підходять для зв'язку між процесами за допомогою спільної пам'яті.

Як вже згадували багато інших, це std::is_always_lock_freeможе бути саме те, що ви справді шукаєте.

Редагування: Для уточнення, типи об'єктів C ++ мають значення вирівнювання, яке обмежує адреси їхніх примірників лише певними кратними повноваженнями двох ( [basic.align]). Ці значення вирівнювання визначені реалізацією для основних типів і не повинні дорівнювати розміру типу. Вони також можуть бути більш суворими, ніж те, що апаратне забезпечення насправді може підтримувати.

Наприклад, x86 (в основному) підтримує нестандартний доступ. Однак ви знайдете більшість компіляторів, що мають alignof(double) == sizeof(double) == 8x86, оскільки нестандартний доступ має безліч недоліків (швидкість, кешування, атомність ...). Але, наприклад, #pragma pack(1) struct X { char a; double b; };або alignas(1) double x;дозволяє мати "неприєднаних" doubles. Отже, коли cppreference говорить про "вирівнювання доступу до пам'яті", імовірно, це робиться з точки зору природного вирівнювання типу для обладнання, не використовуючи тип C ++ таким чином, що суперечить його вимогам вирівнювання (що було б UB).

Ось додаткова інформація: Який фактичний ефект від успішного нерівного доступу на x86?

Будь ласка, ознайомтеся з проникливими коментарями @Peter Cordes нижче!

Ви можете використовувати std::is_always_lock_free

is_lock_free залежить від фактичної системи і її неможливо визначити під час компіляції.

Відповідне пояснення:

Атомні типи також можуть бути іноді без замків, наприклад, якщо для заданої архітектури лише вирівняні пам’яті пам’яті природно є атомними, нерівні об’єкти одного типу повинні використовувати блоки.

Я встановив Visual Studio 2019 на свій Windows-ПК, і цей devenv також має ARMv8-компілятор. ARMv8 дозволяє несанкціонований доступ, але порівнювати та змінювати місцями, замінені доданки та ін. А також чистий навантаження / чистий склад, що використовує ldpабо stp(навантаження пари або запас 32-бітних регістрів), гарантовано є атомним лише тоді, коли вони природно вирівняні.

Тому я написав невелику програму, щоб перевірити, що is_lock_free () повертає для довільного атомарного покажчика. Отже ось код:

#include <atomic>
#include <cstddef>

using namespace std;

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

І це розбирання isLockFreeAtomic

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

Це просто returns true, ака 1.

Ця реалізація вибрана для використання, alignof( atomic<int64_t> ) == 8тому кожна atomic<int64_t>коректно вирівняна. Це дозволяє уникнути необхідності перевірки вирівнювання часу виконання кожного завантаження та зберігання.

(Примітка редактора: це звичайне явище; більшість реалізацій C ++ в реальному житті працюють таким чином. Ось чому std::is_always_lock_freeце так корисно: тому що, як правило, це стосується типів, де is_lock_free()це колись правда.)