История вопроса
До C++20 стандарт C++ не предоставлял потокобезопасных средств для форматированного вывода в общие потоки без ручной синхронизации. Хотя для std::cout была гарантирована синхронизация с C-потоками через sync_with_stdio, это исключало буферизацию и приводило к значительным потерям в производительности. Разработчики обычно использовали std::mutex вокруг каждой вставки, но это полностью сериализовало потоки и не защищало от смешивания, если блокировка была случайно забыта в каком-либо варианте кода. Необходимость в абстракции более высокого уровня, которая осуществляется атомарно, стала критической для многоцелевого многопоточного логирования.
Проблема
Стандартные операции вставки потоков не являются атомарными. Единичный вызов operator<< для сложного типа может вызвать несколько вызовов sputc или sputn для лежащего в основе std::streambuf, и символы из параллельных потоков могут быть перемешаны на этом уровне. Существующие обходные пути, такие как std::stringstream, после которого следовал заблокированный вывод, требовали дополнительной копии всего буфера. Ручная блокировка добавляла громоздкость и создавала риск взаимных блокировок, если исключения происходили до снятия блокировки mutex.
Решение
C++20 представил std::basic_osyncstream (псевдоним std::osyncstream для char), который инкапсулирует std::basic_syncbuf. Этот внутренний буфер аккумулирует весь форматированный вывод локально. Когда вызывается emit() — либо явно, либо при выходе из деструктора — он захватывает мьютекс, связанный с завернутым std::streambuf, и передает весь накопленный контент за одно непрерывное записывание. Это преобразует тонкозернистую блокировку на уровне символов в более грубую блокировку на уровне сообщений, обеспечивая, что никакой другой поток не может смешать символы во время эмиссии.
#include <syncstream> #include <iostream> #include <thread> #include <vector> void worker(int id) { std::osyncstream synced_out(std::cout); synced_out << "Поток " << id << " обрабатывает данные "; // emit() вызывается автоматически здесь, атомарно записывая всю строку } int main() { std::vector<std::jthread> threads; for (int i = 0; i < 10; ++i) { threads.emplace_back(worker, i); } }
Распределенная система баз данных нуждалась в записи JSON-записей о коммитах в центральный журнал аудита из нескольких потоков транзакций. Каждая запись содержала идентификаторы транзакций, временные метки и флаги статуса. Без атомарной эмиссии скобки и кавычки из разных потоков смешивались, производя испорченный JSON, который потоки аналитики не могли разобрать, что приводило к сбоям ночных пакетных заданий.
Одно из решений, рассмотренных командой, предусматривало глобальный std::shared_mutex, позволяющий одновременные чтения, но эксклюзивные записи. Преимущества: Знакомый шаблон синхронизации. Недостатки: Записывающие потоки все равно сериализовались на все время форматирования JSON; высокая конкуренция во время штурмов коммитов вызывала всплески задержек; существовали риски взаимных блокировок, если поток, удерживающий блокировку, выбрасывал исключение до разблокировки.
Другой подход предполагает создание файлов журналов на каждом потоке, объединяемых фоновым потоком. Преимущества: Нулевая конкуренция на пути записи; блокировка не требуется во время обработки транзакций. Недостатки: Сложное управление ротацией журнала и файлами; потеря временного порядка между потоками; увеличенный ввод-вывод на диск из-за нескольких дескрипторов файлов; вероятность потери журналов, если поток объединения выйдет из строя.
Команда приняла std::osyncstream. Каждый диапазон транзакций создает локальный std::osyncstream, оборачивающий общий аудит std::ofstream. JSON формируется во внутреннем буфере и атомарно выводится при выходе из диапазона. Это сократило время удержания блокировки с миллисекунд (время форматирования JSON) до микросекунд (копирование буфера), полностью исключило коррупцию и сохранило хронологический порядок, поскольку emit() сериализует доступ к основному файловому буферу.
Результат: Система выдерживала более 100 000 коммитов в секунду без коррупции журнала, а отладка стала осуществимой, поскольку записи оставались целыми и упорядоченными.
Почему деструктор std::osyncstream вызывает emit() без условий и каковы последствия для безопасности исключений, если основной поток выбрасывает исключение?
Деструктор обеспечивает отсутствие потери буферизованных данных, вызывая emit(). Если emit() выбрасывает исключение (например, заполнение диска), и поскольку деструкторы являются по умолчанию noexcept, вызывается std::terminate немедленно. Кандидаты часто считают, что исключение передается или что буфер тихоdiscarded. Правильная деталь заключается в том, что std::basic_syncbuf предоставляет флаг emit_on_flush и состояние ошибок, доступное через get_wrapped(), но деструктор отдает приоритет завершению программы над тихой потерей данных или утечкой исключений из деструкторов.
Как операции явной очистки (std::flush или std::endl) взаимодействуют с внутренней буферизацией std::osyncstream и почему неправильное использование возвращает производительность до уровня mutex?
Многие кандидаты думают, что std::flush немедленно записывает в основное устройство. В std::osyncstream std::flush инициирует внутренний syncbuf, чтобы подготовиться к эмиссии, но не вызывает сам emit(); он только устанавливает состояние emit_on_flush. Если пользователь вручную вызывает emit() после каждой вставки (имитируя буферизацию единицей), они принуждают блокировку на каждое сообщение, что сводит на нет оптимизацию пакетирования. Эффективность зависит от пакетирования нескольких вставок в один вызов emit() при выходе из диапазона.
Какое ограничение времени жизни связывает завернутый std::streambuf с std::osyncstream и какое неопределенное поведение возникает, если завернутый буфер уничтожается до вызова emit()?
std::osyncstream хранит указатель на завернутый std::streambuf, а не владение. Если вы создаете временный std::ostringstream, передаете его rdbuf() в std::osyncstream, и ostringstream выходит из области видимости до osyncstream, последующие вызовы emit() разыменовывают висячий указатель. Кандидаты часто предполагают, что ведется подсчет ссылок или что osyncstream копирует буфер. Стандарт требует от программиста обеспечить, чтобы завернутый streambuf пережил syncstream, аналогично тому, как std::string_view зависит от исходного хранилища строки.