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

От чего зависит, сможет ли поток пройти через 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>>. Какую гарантию получает читатель относительно самого объекта?

Допустимо ли использовать memory_order_release для атомарной загрузки?

При замене memory_order_acquire на memory_order_consume в загрузке указателя какие данные гарантированно видит поток?

После замены std::mutex на std::shared_mutex почему запись может начать голодать?

В старом интерфейсе поле нельзя заменить на std::atomic без изменения ABI. Что нужно обеспечить, чтобы безопасно использовать его через std::atomic_ref?

Можно ли считать один лишь release-фенс средством публикации обычных данных другому потоку?

После замены join на detach какое ограничение возникает для времени жизни объектов, к которым обращается поток?

Ситуация: несколько потоков получают доступ к лениво инициализируемому объекту. Безопасно ли читать value после успешного std::call_once, не делая его атомарным?

#include <mutex>
#include <thread>

std::once_flag flag;
int value;

void init() {
    value = 42;
}

int read() {
    std::call_once(flag, init);
    return value;
}

Допустим, производитель публикует данные через release-барьер, а потребитель читает их после acquire-барьера: при каком условии такая схема создаёт отношение happens-before?

Гарантируют ли два атомарных поля согласованный снимок состояния при чтении из другого потока?

В многопоточном коде флаг объявлен как volatile: почему это не делает остановку рабочего потока безопасной?