Программирование C++

Оцените выбор порядка памяти для неудачной попытки compare_exchange: может ли он быть release?

В ситуации, где два потока захватывают общие мьютексы в разном порядке, какое условие приводит к взаимной блокировке?

При последовательных relaxed-загрузках одной атомарной переменной может ли второй результат относиться к более старой записи, чем первый?

Поток уже завершился, но объект std::thread остаётся joinable. Что произойдёт при его уничтожении?

Как release- и acquire-барьеры могут обеспечить видимость обычных данных между потоками через одну атомарную переменную?

В следующем фрагменте уведомление выполняется до запуска ожидающего потока. Объясните, почему ожидание не теряется и при каком условии wait возвращается.

#include <atomic>
#include <thread>

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

void worker() {
    ready.wait(false);
}

int main() {
    ready.store(true, std::memory_order_release);
    ready.notify_one();
    std::thread t(worker);
    t.join();
}

После создания std::thread новый поток читает обычные данные, записанные до создания потока. Почему это может быть безопасно без атомика?

Разбор последствий: какую ошибку вызывает проблема ABA в lock-free структуре данных?

Каким образом операция RMW с порядком relaxed может продолжить release-последовательность атомика?

При разработке lock-free счётчика почему одиночная попытка compare_exchange_weak может привести к ошибке, даже если значение не изменилось?

Сопоставьте гарантии lock-free и wait-free для многопоточной операции: какой прогресс они обеспечивают при конкуренции потоков?

Представьте, что два потока одновременно обращаются к обычной переменной, причём один из них иногда записывает значение. Достаточно ли того, что аппаратная запись этого типа выполняется одной инструкцией, чтобы избежать неопределённого поведения?

Гарантирует ли std::atomic<T> отсутствие внутренних блокировок для любого типа T?

Поток завершил запись в обычное поле объекта, после чего другой поток вызвал join. Может ли второй поток безопасно прочитать это поле без атомика или мьютекса?

Найдите ошибку в рассуждении: после разблокировки мьютекса другой поток обязан увидеть изменения, сделанные до этой разблокировки, даже если изменённые данные не являются атомарными?

Два потока выполняют операции над двумя атомиками. Гарантирует ли memory_order_seq_cst, что утверждение не сработает?

#include <atomic>
#include <cassert>
#include <thread>

std::atomic<int> x{0}, y{0};
int r1 = 0, r2 = 0;

int main() {
    std::thread t1([] {
        x.store(1, std::memory_order_seq_cst);
        r1 = y.load(std::memory_order_seq_cst);
    });
    std::thread t2([] {
        y.store(1, std::memory_order_seq_cst);
        r2 = x.load(std::memory_order_seq_cst);
    });
    t1.join(); t2.join();
    assert(!(r1 == 0 && r2 == 0));
}

Объясните механизм: при каком условии операция acquire действительно синхронизируется с операцией release в другом потоке?

Что может произойти, если поток ожидает условную переменную один раз, не проверяя предикат после пробуждения?

В практической задаче два потока увеличивают одну атомарную переменную через отдельное чтение и запись: гарантирует ли атомарность этих операций корректный общий счётчик?

Разберите последствия публикации указателя через атомарную переменную с порядком relaxed: может ли читатель увидеть указатель, но невалидное состояние объекта?