Многопоточность

Ручной захват мьютекса прерван исключением до вызова unlock — как это скажется на следующем захвате?

Достаточно ли вызова notify_one на атомарной переменной, чтобы другой поток увидел обычные данные, записанные до уведомления?

В каких пределах std::latch синхронизирует данные между участниками после завершения ожидания?

Вызов std::async выполнен без указания политики запуска. Какую гарантию о параллельном выполнении даёт такой код?

#include <chrono>
#include <future>
#include <thread>

int work() {
    std::this_thread::sleep_for(std::chrono::milliseconds{10});
    return 42;
}

int main() {
    auto result = std::async(work);
    result.wait();
}

Определите последствие исключения, покинувшего функцию потока, и способ безопасно обработать его. Код должен завершиться без аварийного завершения процесса.

#include <stdexcept>
#include <thread>

void worker() {
    throw std::runtime_error("ошибка");
}

int main() {
    std::thread t(worker);
    t.join();
}

Как следует рассуждать о переходе от совместной блокировки std::shared_mutex к исключительной, если условие проверено под shared lock?

За счёт чего std::scoped_lock предотвращает взаимную блокировку при захвате нескольких мьютексов?

Какую роль играет один и тот же мьютекс при изменении предиката и ожидании на std::condition_variable?

В чём принципиальное различие между std::atomic_signal_fence и std::atomic_thread_fence при обмене данными между потоками?

Если std::mutex::try_lock завершился неудачей, можно ли считать, что поток получил актуальное состояние защищаемых данных?

От чего зависит, сможет ли поток пройти через std::counting_semaphore::acquire?

Чем для атомарной RMW-операции отличается порядок memory_order_acq_rel от memory_order_seq_cst?

Локальная переменная static внутри функции инициализируется при первом одновременном обращении нескольких потоков. Что гарантирует стандарт C++ в такой ситуации?

Что произойдёт при выполнении функции одним потоком, если обычный мьютекс повторно захватывается тем же владельцем?

#include <mutex>

void update(std::mutex& m, int& value) {
    std::lock_guard<std::mutex> first(m);
    ++value;

    if (value == 1) {
        std::lock_guard<std::mutex> second(m);
        value = 2;
    }
}

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

Рассмотрите фрагмент. Как временный std::future влияет на параллельность двух вызовов std::async?

#include <future>
#include <thread>

void work(int) {
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
}

int main() {
    std::async(std::launch::async, work, 1);
    std::async(std::launch::async, work, 2);
}

В практической ситуации поток записал результат в обычное поле, затем вызвал std::promise::set_value, а другой поток получил std::future::get. Что гарантирует такая передача результата о видимости записи?

Как std::jthread организует кооперативную остановку рабочего потока?

Сравнение: чем принципиально отличается std::barrier от std::latch при организации повторяющихся фаз работы потоков?

Ситуация: поток публикует объект через std::atomic<std::shared_ptr<T>>. Какую гарантию получает читатель относительно самого объекта?