C++ C++ · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Атомарные операции и модель памяти

Профессиональный тест проверяет не названия memory_order, а способность доказать видимость данных между потоками. Задания охватывают read-modify-write, release/acquire, happens-before, ABA, ложное разделение кэша и ситуации, где атомарный счётчик не спасает составной инвариант.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 30 вопросов, время — 85 минут. Во многих заданиях недостаточно узнать конструкцию: проследите порядок вычислений, время жизни объектов, владение ресурсами и условия, при которых решение остаётся корректным. После завершения откроются правильные ответы, объяснения, общий результат и тематические шкалы.

Вопрос 1 из 30

Какое итоговое значение counter гарантировано после join обоих потоков?

#include <atomic>
#include <thread>
std::atomic<int> counter{0};
void work(){ for(int i=0;i<100000;++i) counter.fetch_add(1); }
int main(){ std::thread a(work), b(work); a.join(); b.join(); auto x=counter.load(); }

Код не компилируется 200000 Меньше 200000 из-за потерянных обновлений Значение не определено Ровно 100000

Вопрос 2 из 30

Почему `if (flag.load()) flag.store(false);` не является атомарным “забрать флаг”?

std::atomic<bool> flag{true};

void try_take() {
    if (flag.load(std::memory_order_relaxed))
        flag.store(false, std::memory_order_relaxed);
}
// Два потока одновременно вызывают try_take().

atomic запрещает два вызова подряд load и store разделены вмешательством другого потока load и store всегда объединяются компилятором store не записывает значение false Проблема только при seq_cst

Вопрос 3 из 30

Что делает `compare_exchange_weak(expected, desired)` при неудаче сравнения?

std::atomic<int> state{7};
int expected = 5;
const bool changed = state.compare_exchange_weak(
    expected, 9,
    std::memory_order_acq_rel,
    std::memory_order_acquire);
// Чему равен expected, если сравнение не прошло?

Возвращает false, но всё равно записывает desired в атомик Оставляет expected неизменным всегда Записывает фактическое текущее значение атомика в expected Записывает desired в expected Выбрасывает исключение

Вопрос 4 из 30

Когда weak-версия CAS предпочтительна strong?

std::atomic<int> state{0};
int expected = 0;
while (!state.compare_exchange_weak(
    expected, 1,
    std::memory_order_acq_rel,
    std::memory_order_relaxed)) {
    expected = 0;
}

Когда операция должна гарантированно выполниться с первого раза В CAS-цикле, где допустим ложный отказ Strong запрещён в циклах Когда тип поддерживает только weak CAS, но не strong Только без конкуренции

Вопрос 5 из 30

Какое требование у std::atomic_ref<T>?

alignas(std::atomic_ref<int>::required_alignment) int counter = 0;
std::atomic_ref<int> atomic_counter(counter);
atomic_counter.fetch_add(1, std::memory_order_relaxed);

После создания atomic_ref исходный объект можно перемещать, если его адрес сохранён в ссылке T должен быть trivially copyable, объект — достаточно выровнен и жив, а конкурирующие доступы должны соблюдать атомарный протокол Достаточно, чтобы объект был выровнен как обычный T; остальные доступы могут оставаться неатомарными Atomic_ref можно связывать только с объектом, изначально объявленным как std::atomic<T> Ограничения касаются лишь записи; параллельные обычные чтения всегда совместимы с atomic_ref

Вопрос 6 из 30

Что гарантирует memory_order_relaxed?

std::atomic<unsigned> requests{0};
void record_request() {
    requests.fetch_add(1, std::memory_order_relaxed);
}

Атомарность самого объекта без упорядочивания других данных Отсутствие переупорядочивания компилятором вообще Видимость всех предыдущих обычных записей любому потоку Полную последовательную согласованность всей программы Автоматическую блокировку mutex

Вопрос 7 из 30

Какой store нужен издателю для классической публикации данных через ready?

data = build();               // обычные записи
ready.store(true, std::memory_order_release);

`ready.store(true, std::memory_order_release)` `memory_order_acquire` у store `memory_order_acq_rel` запрещён и release тоже `memory_order_relaxed` обязательно достаточно `memory_order_consume` у store

Вопрос 8 из 30

Какой load нужен читателю, чтобы после чтения true безопасно видеть опубликованные данные?

Data data;
std::atomic<bool> ready{false};

// поток-издатель
data = build_data();
ready.store(true, std::memory_order_release);

// поток-читатель
if (ready.load(/* какой порядок? */))
    consume(data);

`memory_order_release` у load `memory_order_relaxed` всегда Обычный bool без atomic `memory_order_acq_rel` у load `ready.load(std::memory_order_acquire)`

Вопрос 9 из 30

Можно ли использовать memory_order_release для load?

std::atomic<int> value{0};
// какой порядок допустим для чистой загрузки?
int observed = value.load(std::memory_order_acquire);

Да, но он означает relaxed Да, это основной способ чтения Только если load возвращает false Да, если операция читает значение целочисленного атомика Нет: release недопустим для load

Вопрос 10 из 30

Чем seq_cst сильнее acquire/release?

std::atomic<int> x{0};
std::atomic<int> y{0};
// Поток A
x.store(1, std::memory_order_seq_cst);
// Поток B
y.store(1, std::memory_order_seq_cst);

Для каждой операции seq_cst вводится отдельная скрытая блокировка Он запрещает кэш процессора Единый глобальный порядок всех операций seq_cst Он делает неатомарные гонки допустимыми Он гарантирует реальное одновременное выполнение

Вопрос 11 из 30

Когда возникает data race?

int value = 0;
// Поток A
value = 1;
// Поток B
std::cout << value; // нет mutex и atomic

Когда все конфликтующие обращения выполняются через один и тот же атомарный объект Когда запись защищена mutex, а все чтения происходят после успешного захвата того же mutex Когда два потока одновременно читают один обычный объект, не изменяя его Когда потоки работают с разными объектами, расположенными в одной cache line Когда есть конфликтующие обращения к одному участку памяти, хотя бы одно из них — запись, и между ними нет happens-before

Вопрос 12 из 30

Что гарантирует успешный lock mutex после unlock другого потока?

std::mutex mutex;
Data shared;
// Поток A
{
    std::lock_guard lock(mutex);
    shared.prepare();
}
// Поток B
{
    std::lock_guard lock(mutex);
    consume(shared);
}

Следующий lock получает mutex, но видимость обычных данных зависит только от порядка процессора Успешный lock синхронизируется только с unlock, выполненным тем же потоком Unlock одного mutex synchronizes-with последующим успешным lock этого же mutex После lock гарантированно видны лишь значения std::atomic, но не обычные поля под защитой mutex Любой unlock одного mutex упорядочивает операции через все остальные mutex программы

Вопрос 13 из 30

Какое отношение создаёт `thread.join()`?

int result = 0;
std::thread worker([&] {
    result = calculate();
});
worker.join();
std::cout << result;

Завершение присоединённого потока happens-before успешного возврата из join Возврат из join может произойти до выполнения последних операций присоединённого потока Join лишь освобождает системный handle и не создаёт отношения happens-before Join упорядочивает только операции над std::atomic, оставляя обычные записи неупорядоченными Join создаёт новый поток, который копирует итоговое состояние завершившегося

Вопрос 14 из 30

Безопасна ли публикация `ptr = new Data; ready.store(true, release)` и чтение ptr после acquire-ready?

Data* ptr = nullptr;
std::atomic<bool> ready{false};

// издатель
ptr = new Data{42};
ready.store(true, std::memory_order_release);

// читатель
if (ready.load(std::memory_order_acquire))
    std::cout << ptr->value;

Нет: указатель ptr обязан быть atomic даже тогда, когда его публикация защищена отдельным release/acquire-флагом Да, обычного bool ready достаточно, если запись ptr выполняется раньше по исходному тексту Нет: для публикации динамического объекта требуется исключительно atomic<shared_ptr<Data>> Да, если acquire-load прочитал значение из соответствующего release-store и после публикации объект не изменяется без синхронизации Да, relaxed-load флага даёт ту же видимость, потому что ready сам является атомарным

Вопрос 15 из 30

Почему double-checked locking с обычным указателем без правильной атомарной публикации опасен?

Widget* instance = nullptr;
std::mutex init_mutex;
Widget* get() {
    if (instance == nullptr) {
        std::lock_guard lock(init_mutex);
        if (instance == nullptr)
            instance = new Widget;
    }
    return instance;
}

Указатель виден до завершения инициализации; возникает гонка Первая проверка указателя заменяет атомарную загрузку благодаря второй проверке под mutex Опасность только при исключении bad_alloc Mutex запрещён внутри if Конструкторы всегда выполняются дважды

Вопрос 16 из 30

Какую гарантию продвижения даёт lock-free операция при продолжающейся конкуренции потоков?

Каждая операция завершится за ограниченное число собственных шагов независимо от действий остальных потоков Каждый compare_exchange в lock-free алгоритме обязан завершаться успехом с первой попытки Все конкурирующие операции завершатся одной группой после освобождения внутренней блокировки Продвижение гарантировано конкретному потоку с наибольшим системным приоритетом Если конкурирующие операции продолжают выполняться, хотя бы одна из них завершится

Вопрос 17 из 30

Что такое проблема ABA в CAS-алгоритме?

A→B→A скрывает промежуточное изменение от CAS Значение меняется A→B и остаётся B, поэтому CAS обнаруживает несовпадение с ожидаемым A Повторное чтение A считается успешным из-за слабого порядка памяти, даже если адрес не менялся Указатель всегда сравнивается по содержимому объекта CAS отклоняет обновление, если значение когда-либо менялось после чтения, даже когда к моменту сравнения оно снова равно A

Вопрос 18 из 30

Почему нельзя сразу delete удалённый узел lock-free стека?

Удаление безопасно, если head объявлен как atomic<Node*> Немедленный delete нарушает только lock-free гарантию, но не корректность памяти После успешного CAS ни один поток уже не может хранить старое значение head Другой поток мог ранее прочитать его адрес и ещё не закончить доступ Проблема только у пустого стека

Вопрос 19 из 30

Что делает hazard pointer?

Откладывает освобождение читаемого узла Перемещает узел на новый адрес перед каждым чтением, чтобы CAS заметил изменение Создаёт частную копию всей структуры для каждого читающего потока Блокирует глобальный mutex Гарантирует wait-free для любого алгоритма

Вопрос 20 из 30

Почему `atomic<T>::is_lock_free()` нужно воспринимать как свойство реализации и конкретного типа?

struct Pair { std::uint64_t lo, hi; };

std::atomic<int> small;
std::atomic<Pair> wide;

std::cout << small.is_lock_free() << ' '
          << wide.is_lock_free();

Значение может различаться для разных объектов одного типа из-за их адреса, даже при одинаковом выравнивании Высокий уровень оптимизации превращает любой atomic<T> в lock-free независимо от платформы Свойство определяется только числом потоков, а представление T на него не влияет Стандарт требует lock-free реализации для любого trivially copyable T одинакового размера Результат зависит от типа, размера, выравнивания и возможностей конкретной реализации

Вопрос 21 из 30

Обнаружит ли ThreadSanitizer логическую ошибку, где все доступы атомарны, но выбран слишком слабый memory_order?

Нет, TSan не понимает atomic вообще Он проверяет только утечки Да, всегда докажет правильный порядок Не обязательно: гонки нет, а протокол может быть ошибочен TSan помечает relaxed как ошибку и предлагает усилить порядок памяти

Вопрос 22 из 30

Что такое litmus test модели памяти?

Минимальный тест возможных исходов потоков Микротест задержки одной атомарной операции без перечисления межпоточных исходов Тест скорости компиляции Большой нагрузочный тест базы данных Проверка синтаксиса atomic

Вопрос 23 из 30

Почему ошибка acquire/release может не проявиться на x86, но проявиться на ARM?

Acquire/release существует в стандарте лишь для архитектур со слабым аппаратным порядком Более сильные аппаратные гарантии x86 могут случайно скрыть недостаточную синхронизацию, заметную на ARM ARM запрещает многопоточный доступ к обычной памяти без системного вызова Компилятор на x86 не переставляет операции, поэтому модель языка можно не учитывать x86 автоматически придаёт acquire/release-смысл любым обычным чтениям и записям

Вопрос 24 из 30

Как повысить шанс проявления редкой ошибки публикации в тесте?

Уменьшить число потоков до одного Добавить задержку только в один поток и считать любой изменившийся результат доказательством ошибки Повторять со синхронным стартом на разных ядрах Запускать сценарий только под отладчиком, полагаясь на изменившийся план выполнения потоков Сделать все переменные volatile

Вопрос 25 из 30

Как документировать CAS-цикл?

Спрятать expected и все повторные попытки в макросе, чтобы вызывающий код не видел протокол Указать лишь, что цикл считается lock-free, не описывая состояния узла Оставить seq_cst по умолчанию и считать это достаточным описанием корректности алгоритма Описать только размер и выравнивание Node, не указывая переходы состояний Зафиксировать инвариант состояния, смысл каждой memory_order и схему безопасного освобождения памяти

Вопрос 26 из 30

Что такое false sharing?

Кэш-линия переезжает между ядрами из-за промахов чтения, даже без записей Два потока обновляют один и тот же логический счётчик через разные ссылки Два shared_ptr имеют общий объект Атомарная операция создаёт отдельную копию значения в кэше каждого ядра Горячие данные разных потоков делят cache line

Вопрос 27 из 30

Как уменьшить false sharing двух горячих счётчиков?

Сделать их соседними bit-field Добавить volatile Заменить int на char Перейти на seq_cst: более сильный порядок памяти устраняет обмен кэш-линией Разнести счётчики по разным cache lines

Вопрос 28 из 30

Когда `atomic::wait/notify` лучше активного spin-loop?

std::atomic<int> state{0};

void wait_until_ready() {
    int old = state.load(std::memory_order_acquire);
    while (old == 0) {
        state.wait(old, std::memory_order_relaxed);
        old = state.load(std::memory_order_acquire);
    }
}

Когда поток уже завершён Когда ожидание короче одной итерации цикла и поток не должен засыпать Всегда для любого однократного load Только если atomic не lock-free При заметном ожидании, чтобы не занимать CPU

Вопрос 29 из 30

Почему два атомика `x` и `y` не обеспечивают инвариант `x + y == 100` для читателя?

std::atomic<int> x{50};
std::atomic<int> y{50};

// писатель переносит единицу из x в y
x.fetch_sub(1, std::memory_order_seq_cst);
y.fetch_add(1, std::memory_order_seq_cst);

// читатель
int snapshot = x.load() + y.load();

`std::atomic<int>` фактически хранит только логическое значение Два отдельных чтения могут наблюдать состояния из разных моментов времени Инвариант нарушается только в редком случае, когда x и y равны `seq_cst` заставляет два отдельных load видеть единый снимок всех атомиков Стандарт запрещает складывать значения, полученные из атомарных объектов

Вопрос 30 из 30

Когда обычный mutex предпочтительнее lock-free структуры?

Когда T нельзя хранить в atomic<T>, хотя состояние легко разбивается на независимые атомарные поля без общего инварианта Когда данные читаются только одним потоком, но API заранее назван concurrent Когда критическая секция короткая: это само по себе доказывает, что lock-free реализация будет сложнее и медленнее на любой платформе При умеренной конкуренции и составном инварианте, который проще защитить одной критической секцией Когда для каждой операции нужна wait-free гарантия, которую обычный mutex не предоставляет

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу