Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

p.set_value();// Запуск t (и тем самым вызов react)

… // Выполнение дополнительной работы

t.join(); // Делаем t неподключаемым

} // (см. раздел 7.3)

Поскольку важно, чтобы поток tстал неподключаемым на всех путях выполнения, ведущих из detect, применение RAII-класса наподобие приведенного в раздела 7.3 класса ThreadRAIIвыглядит целесообразным. На ум приходит следующий код:

void detect()

{

ThreadRAII tr( // RAII-объект

std::thread([] {

p.get_future().wait();

react();

}),

ThreadRAII::DtorAction::join// Рискованно! (См. ниже)

);

… // Поток в tr приостановлен

p.set_value(); // Поток в tr разблокирован

}

Выглядит безопаснее, чем на самом деле. Проблема в том, что, если в первой области “ …” (с комментарием “Поток в trприостановлен”) будет сгенерировано исключение, для pникогда не будет вызвана функция set_value. Это означает, что вызов waitв лямбда- выражении никогда не завершится. А это, в свою очередь, означает, что поток, выполняющий лямбда-выражение, никогда не завершается, а это представляет собой проблему, поскольку RAII-объект trсконфигурирован для выполнения joinдля этого потока в деструкторе. Другими словами, если в первой области кода “ …” будет сгенерировано исключение, эта функция “зависнет”, поскольку деструктор trникогда не завершится.

Имеются способы решения и этой проблемы, но я оставлю их в священном виде упражнения для читателя [26] Разумной отправной точкой для начала изучения этого вопроса является запись в моем блоге от 24 декабря 2013 года в The View From Aristeia , “ThreadRAII + Thread Suspension = Trouble?” . Здесь я хотел бы показать, как исходный код (т.e. без применения ThreadRAII) может быть расширен для приостановки и последующего продолжения не одной задачи реакции, а нескольких. Это простое обобщение, поскольку ключом является применение std::shared_futureвместо std::futureв коде react. Как вы уже знаете, функция-член shareобъекта std::futureпередает владение его общим состоянием объекту std::shared_future, созданному share, а после этого код пишется почти сам по себе. Единственной тонкостью является то, что каждый поток реакции требует собственную копию std::shared_future, которая ссылается на общее состояние, так что объект std::shared_future, полученный от share, захватывается по значению лямбда-выражением, запускаемым в потоке реакции:

std::promise p; // Как и ранее

void detect() // Теперь для нескольких

{ // задач реакции

auto sf=p.get_future(). share(); // Тип sf -

// std::shared_future

std::vector vt; // Контейнер для потоков

// реакции

for (int i = 0; i < threadsToRun; ++i) {

// Ожидание локальной копии sf;

// см. emplace_back в разделе 8.2:

vt.emplace_back([ sf]{ sf.wait();

react(); });

}

… // detect "зависает", если

// здесь генерируется

// исключение!

p.set_value(); // Продолжение всех потоков

…

for (auto& t : vt) { // Все потоки делаются

t.join(); // неподключаемыми;

} // см. "auto&" в разделе 1.2

}

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

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

• Дизайн с использованием флага устраняет эти проблемы, но использует опрос, а не блокировку.

• Переменные условия и флаги могут быть использованы совместно, но получающийся механизм сообщений оказывается несколько неестественным.

• Применение объектов std::promiseи фьючерсов решает указанные проблемы, но этот подход использует динамическую память для общих состояний и ограничен одноразовым сообщением.

Бедный квалификатор volatile! Такой неверно понимаемый… Его даже не должно быть в этой главе, потому что он не имеет ничего общего с параллельным программированием. Но в других языках (например, в Java и С#) он полезен для такого программирования, и даже в С++ некоторые компиляторы перенасыщены volatileс семантикой, делающей его применимым для параллельного программирования (но только при компиляции этими конкретными компиляторами). Таким образом, имеет смысл обсудить volatileв главе, посвященной параллельным вычислениям, хотя бы для того, чтобы развеять окружающую его путаницу.

Возможность С++, которую программисты периодически путают с volatileи которая, безусловно, относится к данной главе, — это шаблон std::atomic. Инстанцирования этого шаблона (например, std::atomic, std::atomic, std::atomicи т.п.) предоставляют операции, которые другими потоками будут гарантированно восприниматься как атомарные. После создания объекта std::atomicоперации над ним ведут себя так, как будто они выполняются внутри критического раздела, защищенного мьютексом, но эти операции обычно реализуются с помощью специальных машинных команд, которые значительно эффективнее применения мьютексов. Рассмотрим код с применением std::atomic:

std::atomicai(0); // Инициализация ai значением 0

ai = 10; // Атомарное присваивание ai значения 10

std::cout << ai; // Атомарное чтение значения ai

++ai; // Атомарный инкремент ai до 11

--ai; // Атомарный декремент ai до 10

В процессе выполнения данных инструкций другие потоки, читающие ai, могут увидеть только значения 0, 10 и 11. Никакие другие значения невозможны (конечно, в предположении, что это единственный поток, модифицирующий ai).

Следует отметить два аспекта этого примера. Во-первых, в инструкции “ std::cout << ai;” тот факт, что aiпредставляет собой std::atomic, гарантирует только то, что атомарным является чтение ai. Нет никакой гарантии атомарности всей инструкции. Между моментом чтения значения aiи вызовом оператора operator<<для записи в поток стандартного вывода другой поток может изменить значение ai. Это не влияет на поведение инструкции, поскольку operator<<для intиспользует передачу выводимого параметра типа intпо значению (таким образом, выведенное значение будет тем, которое прочитано из ai), но важно понимать, что во всей этой инструкции атомарным является только чтение значения ai.