C++ C++ · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний · 👥 2 прошли

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

Тест разбирает жизненный цикл потока, защиту общих данных, ожидание условий и взаимные блокировки. Вопросы не сводятся к названиям примитивов: нужно увидеть гонку, выбрать область блокировки и объяснить, почему код иногда зависает лишь под нагрузкой.

Отвечено: 0 из 25

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 25 вопросов, время — 70 минут. Во многих заданиях недостаточно узнать конструкцию: проследите порядок вычислений, время жизни объектов, владение ресурсами и условия, при которых решение остаётся корректным. После завершения откроются правильные ответы, объяснения, общий результат и тематические шкалы.

Вопрос 1 из 25

Что произойдёт, если уничтожить joinable std::thread?

void start_worker() {
    std::thread worker([] { process_queue(); });
    // выход из функции: worker всё ещё joinable
}

Деструктор подождёт пять секунд Будет вызван std::terminate Ничего Деструктор переводит поток в detached-состояние и сразу продолжает работу Деструктор выполняет join и блокируется до завершения потока

Вопрос 2 из 25

Чем join отличается от detach?

std::thread worker(run);
if (wait_for_result) {
    worker.join();
} else {
    worker.detach();
}

join запускает новый поток `join` ждёт, `detach` отделяет без возможности join detach немедленно завершает поток detach копирует все данные потока Обе функции только меняют приоритет

Вопрос 3 из 25

Почему передача `std::ref(x)` нужна, если функция потока принимает int&?

void increment(int& value) { ++value; }

int counter = 0;
std::thread worker(increment, std::ref(counter));
worker.join();
std::cout << counter;

`thread` копирует, `ref` передаёт ссылку ref делает x атомарным Без ref x станет const global ref запускает поток синхронно Поток не поддерживает int

Вопрос 4 из 25

Что происходит с исключением, вышедшим из функции потока?

std::thread worker([] {
    load_config();          // может бросить
    serve_requests();
});
worker.join();

Если исключение не поймано внутри функции потока, вызывается `std::terminate` `join()` возвращает `std::exception_ptr`, который вызывающий поток обязан проверить Функция потока запускается повторно после раскрутки своего стека Исключение сохраняется в объекте `std::thread` и выходит наружу при `join()` Среда игнорирует исключение и завершает только функцию потока

Вопрос 5 из 25

Какое преимущество std::jthread?

void worker(std::stop_token stop) {
    while (!stop.stop_requested()) {
        process_one();
    }
}
std::jthread thread(worker);

Автоостановка, join в деструкторе и stop_token Он всегда быстрее std::thread Он не может принимать аргументы jthread разрешено создавать только в главном потоке программы Он гарантирует lock-free выполнение

Вопрос 6 из 25

Почему `counter++` из двух потоков без синхронизации является гонкой данных?

int counter = 0;

auto work = [&] {
    for (int i = 0; i < 100'000; ++i)
        ++counter;
};

std::thread a(work), b(work);
a.join(); b.join();

Проблема только в выводе ++ всегда атомарен для int Потоки выполняются строго по очереди Чтение, изменение и запись могут пересечься Гонка возможна только на double

Вопрос 7 из 25

Что делает `std::lock_guard lock(m);`?

std::mutex mutex;
std::vector<int> queue;

void push(int value) {
    std::lock_guard lock(mutex);
    queue.push_back(value);
}

Создаёт независимую копию mutex и блокирует только эту копию Блокирует mutex при создании и разблокирует его при разрушении guard Запускает новый поток, которому передаётся владение mutex Делает все обращения к полям текущего объекта атомарными Проверяет состояние mutex, но не меняет его и не ждёт освобождения

Вопрос 8 из 25

Почему критическую секцию стоит делать как можно короче, но не короче инварианта?

std::scoped_lock lock(account.mutex);
account.balance -= amount;
account.history.push_back(Transaction{amount});
account.version++;
// все три изменения образуют один инвариант

Lock должен покрывать весь инвариант, но не лишнюю работу Размер секции влияет только на бинарник Mutex ускоряет только длинные секции Короткие секции запрещены unlock отменяет изменения, сделанные после lock, если критическая секция была слишком длинной

Вопрос 9 из 25

Как безопасно заблокировать два mutex без фиксированного ручного порядка?

std::mutex left;
std::mutex right;

void transfer() {
    std::scoped_lock lock(left, right);
    move_items();
}

`m1.lock(); m2.lock();` в каждом месте в разном порядке Проверять адрес mutex `std::scoped_lock lock(m1, m2);` Сделать оба mutex global volatile Использовать sleep между lock

Вопрос 10 из 25

Почему отдельные mutex для balance и transaction_count могут быть недостаточны?

std::mutex balance_mutex;
std::mutex count_mutex;
int balance;
int transaction_count;
// читатель должен видеть согласованную пару значений

Поля, доступ к которым окружён разными mutex, получают атомарные операции от компилятора Каждый mutex занимает слишком много памяти Стандарт запрещает защищать поля одного объекта разными mutex Проблема только при отрицательном balance Два поля образуют единый инвариант

Вопрос 11 из 25

Почему wait вызывают в цикле или с предикатом?

std::unique_lock lock(mutex);
ready_cv.wait(lock, [&] {
    return stopped || !queue.empty();
});

Цикл нужен только timed_wait; обычное ожидание по уведомлению не требует проверки состояния Предикат создаёт служебный поток, который повторяет notify после ложного пробуждения Wait по контракту возвращается ровно один раз после каждого notify, поэтому цикл лишь повторяет проверку тайм-аута Condition variable сама хранит очередь пользовательских данных и извлекает элемент в wait Поток может проснуться без нужного состояния, а состояние могло снова измениться до получения mutex

Вопрос 12 из 25

Почему `std::condition_variable::wait` принимает unique_lock, а не lock_guard?

std::mutex mutex;
std::condition_variable ready;
bool done = false;

std::unique_lock lock(mutex);
ready.wait(lock, [&] { return done; });

Lock_guard не умеет связываться ни с одним типом mutex Unique_lock всегда быстрее lock_guard и потому выбран для всех блокирующих операций Condition_variable совместима только с recursive_mutex, который lock_guard не поддерживает Wait копирует объект блокировки в condition_variable, поэтому нужен копируемый unique_lock Wait должен атомарно отпустить mutex на время сна и снова захватить его перед возвратом

Вопрос 13 из 25

Что не так с ожиданием только уведомления без флага/очереди состояния?

// Поток A
{
    std::lock_guard lock(mutex);
    ready = true;
}
cv.notify_one();

// Поток B запускается позже
std::unique_lock lock(mutex);
cv.wait(lock);

condition_variable хранит внутренний флаг уведомления до следующего wait Mutex запрещает ранний notify Проблема только с notify_all notify до wait не запоминается Уведомления всегда сохраняются навсегда

Вопрос 14 из 25

Нужно ли держать mutex во время notify_one?

Нет, mutex вообще не нужен для состояния Нет; обычно notify делают после изменения и unlock Только notify_all требует lock Да, стандарт требует держать его до пробуждения Notify сам блокирует mutex навсегда

Вопрос 15 из 25

Какой шаблон корректен для потребителя очереди?

Ждать только notify и сразу читать front После wait всегда считать очередь непустой Проверить empty без mutex Использовать sleep как синхронизацию Ждать `!queue.empty() || stopped` и различать оба случая

Вопрос 16 из 25

Как возникает классический deadlock с двумя mutex?

Один поток вызывает join после завершения другого Поток A держит m1 и ждёт m2, а поток B держит m2 и ждёт m1 Оба потока читают разные const-данные Используется один lock_guard Mutex создаётся на стеке

Вопрос 17 из 25

Какое простое правило снижает риск deadlock?

Делить каждый mutex на два, сохраняя прежний непоследовательный порядок Менять порядок захвата между вызовами, чтобы циклы ожидания возникали реже статистически Использовать единый глобальный порядок блокировок или захватывать набор через `std::scoped_lock` Использовать `try_lock` с повтором для каждого mutex по прежнему непоследовательному порядку Не вызывать unlock вручную и удерживать все mutex до завершения процесса

Вопрос 18 из 25

Почему опасно вызывать пользовательский callback под внутренним mutex?

Callback может повторно войти или взять неизвестные locks Опасность только для noexcept callback Перед входом в callback среда выполнения временно освобождает mutex и затем захватывает его снова Mutex становится recursive Функции нельзя вызывать под lock синтаксически

Вопрос 19 из 25

Решает ли recursive_mutex проблему архитектуры с повторным входом?

При выходе из внешнего lock recursive_mutex откатывает изменения, сделанные повторным входом Нет, его нельзя блокировать повторно Да, устраняет все deadlock Нет: он лишь убирает самоблокировку одного потока Он превращает код в lock-free

Вопрос 20 из 25

Какой риск у вызова `future.get()` под mutex, если задача может потребовать тот же mutex?

std::mutex mutex;
std::future<int> result;

{
    std::lock_guard lock(mutex);
    result = std::async([&] {
        std::lock_guard inner(mutex);
        return calculate();
    });
    std::cout << result.get();
}

Риск возникает только у пустого future без связанного общего состояния `get()` всегда неблокирующий и немедленно возвращает состояние future Асинхронная задача не может обращаться к mutex, удерживаемому вызывающим кодом Возможен deadlock: поток ждёт задачу, а задача — удерживаемый им mutex `future::get` временно отпускает все mutex текущего потока на время ожидания

Вопрос 21 из 25

Что обнаруживает ThreadSanitizer?

Любой логически неверный порядок сообщений, даже при корректной синхронизации Нарушения правила единственного определения между объектными файлами Все возможные взаимные блокировки, даже если соответствующий путь не выполнялся Утечки файловых дескрипторов и других внешних ресурсов Гонки данных и часть ошибок синхронизации, проявившихся в выполненном запуске

Вопрос 22 из 25

Как сделать тест потерянного обновления более воспроизводимым?

Вставить одиночную задержку перед инкрементом вместо управляемого одновременного старта потоков Сделать counter const Отключить оптимизацию как единственную меру Защитить обновление mutex и считать исчезновение потерянных записей воспроизведением исходной гонки Barrier на старте и много конфликтующих операций

Вопрос 23 из 25

Как проверить корректное завершение очереди работников?

Закрыть, разбудить, join, проверить задачи Завершить main без join Вызвать detach для всех Проверить только размер mutex Удалить очередь до уведомления

Вопрос 24 из 25

Почему тест, прошедший тысячу раз, не доказывает отсутствия гонки?

Гонки возникают только один раз Тысяча запусков всегда математически достаточна Компилятор фиксирует расписание Невозможно перебрать все расписания потоков Mutex не зависит от расписания

Вопрос 25 из 25

Как локализовать редкий deadlock?

Сравнить только загрузку CPU Перезапустить без журналов Заменить все mutex на recursive_mutex, сохранив прежний порядок их захвата Снять стеки и найти цикл удерживаемых locks Заменить mutex на volatile bool

Ответьте на все 25 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу