Краткий ответ

std::lock_guard захватывает мьютекс в конструкторе и освобождает его в деструкторе. Поэтому при return, исключении или обычном завершении блока деструктор вызывается автоматически, и мьютекс разблокируется без отдельного вызова unlock().

Исторический контекст

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

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

Постановка проблемы

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

Неверно также считать, что сам мьютекс уничтожается вместе с lock_guard: объект-сторож освобождает блокировку, но не владеет временем жизни мьютекса. Мьютекс должен существовать дольше lock_guard.

Подробное решение

При создании std::lock_guard вызывается mutex.lock(). Если захват успешен, объект становится ответственным за последующий вызов mutex.unlock() в своём деструкторе.

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

#include <mutex>

std::mutex data_mutex;

void update_data() {
    std::lock_guard<std::mutex> lock(data_mutex);
    if (/* ошибка */) return;
    // Работа с защищёнными данными.
}

В примере return уничтожает локальный lock, после чего вызывается unlock(). Объект std::lock_guard нельзя копировать: копирование могло бы привести к нескольким объектам, пытающимся управлять одной блокировкой.

std::lock_guard подходит для простой блокировки на весь срок жизни области видимости. Если нужно вручную временно освобождать мьютекс, использовать условную блокировку или одновременно захватить несколько мьютексов, обычно выбирают std::unique_lock или std::scoped_lock соответственно.

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

Ситуация из практики

Поток обновляет состояние кэша и может завершить операцию по нескольким веткам: при отсутствии данных, ошибке валидации или успешном обновлении. Ручная схема lock()/unlock() требует проверять каждую ветку и отдельно учитывать исключения.

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

Выбран std::lock_guard, потому что критическая секция едина и должна удерживать мьютекс до выхода из функции. В результате все пути завершения автоматически освобождают блокировку, а область её действия видна непосредственно из области видимости объекта.

Что кандидаты часто упускают

Что произойдёт, если мьютекс уничтожится раньше std::lock_guard?

Деструктор lock_guard попытается обратиться к уже уничтоженному объекту мьютекса. Это неопределённое поведение, поэтому мьютекс должен иметь время жизни не меньше, чем охраняющий его lock_guard.
Гарантирует ли std::lock_guard отсутствие гонок данных?

Нет. Он гарантирует только захват и освобождение конкретного мьютекса. Если другой поток обращается к тем же данным без этого мьютекса либо используется другой мьютекс, синхронизация нарушается и гонка данных всё ещё возможна.
Можно ли передать уже захваченный мьютекс в std::lock_guard?

Да, существует конструктор с тегом std::adopt_lock, но он требует, чтобы текущий поток уже владел мьютексом. Нарушение этого предусловия приводит к некорректному управлению блокировкой. Без специальной необходимости безопаснее позволить lock_guard самому выполнить захват.