Энтони Уильямс - Параллельное программирование на С++ в действии. Практика разработки многопоточных программ

Поскольку thread_interrupted— исключение, то при вызове кода, который может быть прерван, следует принимать все обычные для исключений меры предосторожности, чтобы не было утечки ресурсов, и структуры данных оставались согласованными. Часто желательно завершать поток в случае прерывания, так чтобы исключение можно было просто передать вызывающей функции. Но если позволить исключению выйти за пределы функции потока, переданной конструктору std::thread, то будет вызвана функция std::terminate(), что приведёт к завершению всей программы. Чтобы не помещать обработчик catch(thread_interrupted)в каждую функцию, которая передаётся interruptible_thread, можно включить блок catchв обертку, служащую для инициализации interrupt_flag. Тогда распространять необработанное исключение будет безопасно, так как завершится лишь отдельный поток. Инициализация потока в конструкторе interruptible_threadпри таком подходе выглядит следующим образом:

internal_thread = std::thread([f, &p] {

p.set_value(&this_thread_interrupt_flag);

try {

f();

} catch(thread_interrupted const&) {}

});

А теперь рассмотрим конкретный пример, когда прерывание оказывается полезно.

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

В следующем листинге показана возможная реализация управления потоками в такой программе.

Листинг 9.13.Фоновый мониторинг файловой системы

std::mutex config_mutex;

std::vector background_threads;

void background_thread(int disk_id) {

while (true) {

interruption_point(); ← (1)

fs_change fsc = get_fs_changes(disk_id); ← (2)

if (fsc.has_changes()) {

update_index(fsc); ← (3)

}

}

}

void start_background_processing() {

background_threads.push_back(

interruptible_thread(background_thread, disk_1));

background_threads.push_back(

interruptible_thread(background_thread, disk_2));

}

int main() {

start_background_processing(); ← (4)

process_gui_until_exit(); ← (5)

std::unique_lock lk(config_mutex);

for (unsigned i = 0; i < background_threads.size(); ++i) {

background_threads[i].interrupt(); ← (6)

}

for (unsigned i = 0; i < background_threads.size(); ++i) {

background_threads[i].join(); ← (7)

}

}

В самом начале запускаются фоновые потоки (4). Затем главный поток продолжает обслуживать пользовательский интерфейс (5). Когда пользователь хочет выйти из приложения, фоновые потоки прерываются (6), после чего главный поток ждет их завершения (7), и только потом выходит сам. Каждый фоновый поток исполняет цикл, в котором следит за изменениями на диске (2)и обновляет индекс (3). На каждой итерации цикла поток проверяет, не прервали ли его, вызывая функцию interruption_point() (1).

Почему мы прерываем все потоки до того, как начинать ждать их завершения? Почем нельзя прервать один поток, дождаться его, потом прервать следующий и так далее? Все из-за параллелизма . Поток не завершается сразу после прерывания, так как должен добраться до очередной точки прерывания, а затем, перед выходом, выполнить все деструкторы и код обработки исключений. Если главный поток будет присоединять прерванные потоки сразу после прерывания, то ему придётся ждать, хотя в это время он мог бы делать полезную работу — прерывать другие потоки. Поэтому мы поступаем по-другому — начинаем ждать только тогда, когда больше никакой работы не осталось (все потоки уже прерваны). Заодно это позволяет прерываемым потокам обрабатывать прерывания параллельно, так что общее время завершения, возможно, уменьшится.

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

В этой главе мы рассмотрели «продвинутые» способы управления потоками: пулы и прерывание потоков. Мы видели, как использование локальных очередей работ и занимания работ может снизить накладные расходы на синхронизацию и потенциально увеличить пропускную способность пула потоков. Кроме того, мы поняли, что выполнение других выбранных из очереди задач во время ожидания завершения подзадачи устраняет возможность взаимоблокировки.

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

■ Ошибки, связанные с параллелизмом.

■ Поиск ошибок путем тестирования и анализа кода коллегами.

■ Разработка тестов для многопоточных приложений.

■ Тестирование производительности многопоточных приложений.

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

Тестирование и отладка — две стороны одной медали. Вы прогоняете тесты, чтобы найти в программе ошибки, и отлаживаетесь, чтобы эти ошибки устранить. Если повезёт, то придётся устранять только ошибки, найденные вашими собственными тестами, а не конечными пользователями. Но прежде чем приступать непосредственно к вопросам тестирования и отладки, важно понять, какие вообще могут возникать проблемы.

В параллельной программе могут быть любые ошибки, в этом отношении она не представляет собой ничего особенного. Однако есть ряд ошибок, непосредственно связанных с параллелизмом, и вот они-то будут нам особенно интересны. Как правило, эти ошибки попадают в одну из двух категорий: