Historia pytania
Przed C++20, standard C++ nie oferował wbudowanego mechanizmu thread-safe do formatowanego wypisywania danych do współdzielonych strumieni bez manualnej synchronizacji. Podczas gdy std::cout zapewniał synchronizację z strumieniami C za pomocą sync_with_stdio, powodowało to brak buforowania i prowadziło do poważnego spadku wydajności. Programiści zazwyczaj opakowywali każdy wstawnik w std::mutex, ale to całkowicie uszeregowało wątki i nie zabezpieczało przed przeplataniem się w przypadku, gdy zamek został zapomniany na nawet jednej ścieżce kodu. Potrzeba wyższej abstrakcji, która atomowo grupowałaby dane wyjściowe, stała się krytyczna dla wielowątkowego logowania o wysokiej przepustowości.
Problem
Standardowe operacje wstawiania do strumieni nie są atomowe. Pojedyncza wywołanie operator<< dla złożonego typu może wywołać wiele wywołań sputc lub sputn do podstawowego std::streambuf, a współbieżne wątki mogą mieć swoje znaki przeplatane na tym granicznym poziomie. Istniejące obejścia, takie jak std::stringstream, po którym następowało zablokowane wyjście, wymagały dodatkowej kopii całego bufora. Ręczne blokowanie dodawało nadmiarowe elementy kodu i ryzykowało zakleszczeniami, jeśli wyjątki wystąpiły przed odblokowaniem mutexa.
Rozwiązanie
C++20 wprowadził std::basic_osyncstream (alias std::osyncstream dla char), który kapsułkuje std::basic_syncbuf. Ten wewnętrzny bufor lokalnie gromadzi wszystkie formatowane dane wyjściowe. Gdy wywoływana jest metoda emit()—zarówno explicite, jak i przez destruktor—nabywa mutex powiązany z opakowanym std::streambuf i transferuje całą skumulowaną treść w jednym, ciągłym zapisie. To przekształca drobnoziarniste blokowanie na poziomie znaków w blokowanie na poziomie wiadomości, zapewniając, że żaden inny wątek nie może przeplatać znaków podczas emisji.
#include <syncstream> #include <iostream> #include <thread> #include <vector> void worker(int id) { std::osyncstream synced_out(std::cout); synced_out << "Wątek " << id << " przetwarza dane "; // emit() wywołane automatycznie tutaj, atomowo zapisując cały wiersz } int main() { std::vector<std::jthread> threads; for (int i = 0; i < 10; ++i) { threads.emplace_back(worker, i); } }
Rozproszony system baz danych potrzebował zapisywać rekordy zatwierdzenia JSON do centralnego logu audytu z wielu wątków transakcyjnych. Każdy rekord zawierał identyfikatory transakcji, znaczniki czasu i flagi statusu. Bez atomowej emisji, nawiasy klamrowe i cudzysłowy z różnych wątków mieszane były, co prowadziło do uszkodzonego JSON, którego analityczne potoki downstream nie mogły przetworzyć, co powodowało niepowodzenie nocnych zadań wsadowych.
Jednym z rozważanych rozwiązań był globalny std::shared_mutex, umożliwiający równoczesne odczyty, ale ekskluzywne zapisy. Plusy: Znany wzorzec synchronizacji. Minusy: Zapisujący wciąż byli uszeregowani przez cały czas formatowania JSON; wysoka kontencja podczas burz zatwierdzania powodowała skoki latencji; istniały ryzyka zakleszczenia, jeśli wątek trzymający blokadę zgłosił wyjątek przed odblokowaniem.
Innym rozważanym podejściem były pliki dziennika per-wątek łączone przez wątek w tle. Plusy: Brak kontencji na ścieżce zapisu; nie było potrzeby blokowania podczas przetwarzania transakcji. Minusy: Złożona rotacja dziennika i zarządzanie plikami; utrata porządku temporalnego między wątkami; zwiększone I/O na dysku z wielu uchwytów plików; potencjalna utrata logów, jeśli wątek łączenia uległ awarii.
Zespół przyjął std::osyncstream. Każdy zakres transakcji tworzy lokalny std::osyncstream, który ob wrapsuje wspólny audyt std::ofstream. JSON jest budowany w wewnętrznym buforze i atomowo emitowany przy wyjściu z zakresu. To zmniejszyło czas trzymania blokady z milisekund (czas formatowania JSON) do mikrosekund (kopiowanie bufora), całkowicie wyeliminowało uszkodzenia i zachowało chronologiczną kolejność, ponieważ emit() serializuje dostęp do podstawowego bufora plików.
Wynik: System obsługiwał ponad 100 000 zatwierdzeń na sekundę bez uszkodzenia logów, a debugowanie stało się wykonalne, ponieważ rekordy pozostały nienaruszone i uporządkowane.
Dlaczego destruktor std::osyncstream wywołuje emit() bezwarunkowo i jakie są implikacje dotyczące bezpieczeństwa wyjątków, jeśli podstawowy strumień zgłasza wyjątek?
Destruktor zapewnia, że żadne buforowane dane nie zostaną utracone, wywołując emit(). Jeśli emit() wyrzuca wyjątek (np. pełny dysk), a ponieważ destruktory są automatycznie noexcept, std::terminate jest wywoływane natychmiast. Kandydaci często sądzą, że wyjątek propaguje się lub że bufor jest cicho porzucany. Poprawny szczegół jest taki, że std::basic_syncbuf udostępnia flagę emit_on_flush i stan błędu dostępny za pomocą get_wrapped(), ale destruktor priorytetowo traktuje zakończenie programu ponad cichą utratę danych lub wyciek wyjątku z destruktorów.
Jak operacje wymuszające opróżnianie (std::flush lub std::endl) oddziałują z wewnętrznym buforowaniem std::osyncstream i dlaczego niewłaściwe użycie przywraca wydajność do poziomu mutexa?
Wielu kandydatów uważa, że std::flush natychmiast zapisuje do podstawowego urządzenia. W std::osyncstream, std::flush uruchamia wewnętrzny syncbuf w celu przygotowania do emisji, ale nie wywołuje samego emit(); ustawia tylko stan emit_on_flush. Jeśli użytkownik ręcznie wywołuje emit() po każdym wstawieniu (naśladując buforowanie jednostkowe), wymusza blokowanie per komunikat, co niweczy optymalizację grupowania. Wydajność polega na grupowaniu wielu wstawek w jeden sposób wywołania emit() w momencie wyjścia z zakresu.
Jakie ograniczenie żywotności wiąże opakowany std::streambuf z std::osyncstream i jakie nieokreślone zachowanie występuje, jeśli opakowany bufor zostanie zniszczony przed emit()?
std::osyncstream przechowuje wskaźnik do opakowanego std::streambuf, a nie własność. Jeśli utworzysz tymczasowy std::ostringstream, przekażesz jego rdbuf() do std::osyncstream, a ostringstream wyjdzie z zakresu przed osyncstream, kolejne wywołania emit() będą dereferencjonować wskaźnik wiszący. Kandydaci często zakładają, że istnieje liczenie referencji lub że osyncstream kopiuje bufor. Standard wymaga, aby programista zapewnił, że opakowany streambuf przeżywa syncstream, podobnie jak std::string_view zależy od podstawowego przechowywania ciągu.