Подводные камни C++. Решаем загадки неопределённого поведения, ч. 2

Пример состояния гонки, как не надо создавать потоки в С++. По мотивам найденного в реальном софте. Воспроизводилось только на определённой архитектуре.

Будет печатать "111 -1", а не как предполагается "111 999", "X() finished" напечатает после чисел. Потому что поток стартует раньше чем завершится инициализация класса. Вместо задержки в 1мс была инициализация кучи других классов.

#include <stdio.h>
#include <chrono>
#include <thread>
#include <cstring>
#include <new>

struct S {
    S() {
        std::this_thread::sleep_for(std::chrono::milliseconds(1));
    }
};

struct X {
    void worker() { printf("%d %d\n", first, last); }
    X() : t(&X::worker, this) { puts("X() finished"); }
    int first = 111;
    std::thread t;
    S s;
    int last = 999;
};

int main() {
    alignas(X) char buf[sizeof(X)];
    memset(buf, -1, sizeof(buf));
    new(buf) X();
}

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

Вы бы хоть другой пример выбрали. Потому что там все это происходит ну совсем не так. И никаких гонок на уровне клиентов там нет и быть не может.

Второй момент. Есть разделяемые ресурсы, совместное использование которых приходится регулировать разработчику. Например, разделяемая память. И есть ресурсы, за совместное использование которых отвечает система. Например, очереди, сокеты, файлы.

Строго говоря, к С++ все это вообще никакого отношения не имеет, это вопрос общей архитектуры.

Как пример - у вас есть несколько потоков или процессов (не важно), которым необходимо обмениваться некоторой информацией. И вы знаете что скорость обмена для вас не является критичным параметром в данной задаче (но т.е. будет там 1мс на блок или 1мкс не играет роли на фоне всего остального).

И вот здесь нет смысла связываться с разделяемой памятью - это слишком сложно и оправданно только тогда когда требуется предельная скорость именно обмена данными.

Можно использовать системные средства. Например, именованные локальные сокеты (UNIX socket). Или майлслоты (Win). Или очереди (*usrq, *dtaq в as/400). Каждый поток (процесс) создает свой объект с уникальным именем который является "почтовым ящиком" для него. Он оттуда будет читать все, что ему посылают другие. Все остальные могут туда писать все что нужно передать данному потоку.

И здесь все вопросы синхронизации отдаются на откуп системе, она за всем этим следит. Лично использовал такой подход в ситуации когда было три потока - один коммуникация с удаленными контроллерами по UDP, второй коммуникация с интерфейсными клиентами по TCP и третий - обработка и маршрутизация посылок от клиента к контроллеру и от контроллера к клиенту. И никаких гонок, никаких проблем с синхронизацией при минимальных затратах.

Второй пример, с чем часто сталкиваюсь сейчас - параллельная обработка больших объемов данных. Есть головное задание, которое производит первичный отбор данных для обработки, есть несколько (5-10) заданий-обработчиков которые уже занимаются обработкой каждого блока данных. И есть конвейер (у нас - *usrq). Головное задание выкладывает отобранные данные на конвейер, обработчики их оттуда разбирают и обрабатывают. И опять - вся синхронизация на системе. На разработчике только "положить в очередь" и "взять из очереди".

Пример уб с семантикой перемещений неверный, в c++ для классов с user-defined деструктором не генерятся move-конструктор и move-оператор= -> resource просто копируется, никакого уб там нет