Historique de la question
Avant C++20, la norme C++ ne proposait aucun moyen sûr pour les threads pour une sortie formatée vers des flux partagés sans synchronisation manuelle. Bien que std::cout ait été garanti de se synchroniser avec les flux C via sync_with_stdio, cela empêchait la mise en mémoire tampon et provoquait une sévère dégradation des performances. Les développeurs enveloppaient généralement std::mutex autour de chaque insertion, mais cela sérialisait entièrement les threads et ne protégeait pas contre l'entrelacement si le verrou était oublié dans même un chemin de code. Le besoin d'une abstraction de niveau supérieur qui regroupe la sortie de manière atomique est devenu critique pour un logging multithreadé à haut débit.
Le problème
Les opérations d'insertion standard de flux ne sont pas atomiques. Une seule invocation de operator<< pour un type complexe peut déclencher plusieurs appels à sputc ou sputn vers le std::streambuf sous-jacent, et des threads concurrents peuvent avoir leurs caractères entrelacés à ce niveau granulaire. Des solutions de contournement existantes comme std::stringstream suivies d'une sortie verrouillée nécessitaient une copie supplémentaire de l'intégralité du tampon. Le verrouillage manuel ajoutait de la boilerplate et risquait des interblocages si des exceptions se produisaient avant le déverrouillage du mutex.
La solution
C++20 a introduit std::basic_osyncstream (alias std::osyncstream pour char), qui encapsule un std::basic_syncbuf. Ce tampon interne accumule toute la sortie formatée localement. Lorsque emit() est invoqué—soit explicitement, soit par le destructeur—il acquiert un mutex associé au std::streambuf enveloppé et transfère l'intégralité du contenu accumulé dans une seule écriture contiguë. Cela transforme le verrouillage au niveau des caractères en un verrouillage au niveau des messages, garantissant qu'aucun autre thread ne peut entrelacer les caractères pendant l'émission.
#include <syncstream> #include <iostream> #include <thread> #include <vector> void worker(int id) { std::osyncstream synced_out(std::cout); synced_out << "Thread " << id << " traitement des données "; // emit() est appelé automatiquement ici, écrivant atomiquement la ligne complète } int main() { std::vector<std::jthread> threads; for (int i = 0; i < 10; ++i) { threads.emplace_back(worker, i); } }
Un système de base de données distribué devait écrire des enregistrements de validation JSON dans un journal d'audit central à partir de plusieurs threads de transaction. Chaque enregistrement contenait des identifiants de transaction, des horodatages et des indicateurs de statut. Sans émission atomique, les accolades et les guillemets de différents threads se mélangeaient, produisant un JSON corrompu que les chaînes de traitement d'analytique en aval ne pouvaient pas analyser, causant des échecs des tâches de lot nocturnes.
Une solution envisagée était un std::shared_mutex global permettant des lectures concurrentes mais des écritures exclusives. Avantages : Modèle de synchronisation familier. Inconvénients : Les écrivains étaient toujours sérialisés pour toute la durée du formatage JSON ; une forte contention lors des tempêtes de validation provoquait des pics de latence ; des risques d'interblocage existaient si un thread tenant le verrou lançait une exception avant le déverrouillage.
Une autre approche envisagée consistait en des fichiers de log par thread fusionnés par un thread de fond. Avantages : Aucune contention sur le chemin d'écriture ; aucun verrouillage requis pendant le traitement de la transaction. Inconvénients : Gestion complexe de la rotation des journaux et des fichiers ; perte de l'ordre temporel entre les threads ; augmentation des E/S disque à partir de plusieurs poignées de fichier ; potentiel de perte de journaux si le thread de fusion plantait.
L'équipe a adopté std::osyncstream. Chaque portée de transaction crée un std::osyncstream local enveloppant le std::ofstream d'audit partagé. Le JSON est construit dans le tampon interne et émis de manière atomique à la sortie de la portée. Cela a réduit le temps de maintien du verrou de millisecondes (durée de formatage JSON) à microsecondes (copie du tampon), éliminé la corruption entièrement, et préservé l'ordre chronologique puisque emit() sérialise l'accès au tampon de fichier sous-jacent.
Résultat : Le système a soutenu plus de 100 000 validations par seconde sans corruption de journal, et le débogage est devenu réalisable car les enregistrements sont restés intacts et ordonnés.
Pourquoi le destructeur de std::osyncstream appelle emit() de manière inconditionnelle, et quelles sont les implications en matière de sécurité des exceptions si le flux sous-jacent lance une exception ?
Le destructeur garantit qu'aucune donnée mise en mémoire tampon n'est perdue en invoquant emit(). Si emit() lance une exception (par exemple, disque plein), et puisque les destructeurs sont implicitement noexcept, std::terminate est appelé immédiatement. Les candidats pensent souvent que l'exception se propage ou que le tampon est silencieusement rejeté. Le détail correct est que std::basic_syncbuf fournit un indicateur emit_on_flush et un état d'erreur accessible via get_wrapped(), mais le destructeur privilégie l'arrêt du programme par rapport à une perte silencieuse de données ou une fuite d'exception provenant des destructeurs.
Comment les opérations de vidage explicites (std::flush ou std::endl) interagissent-elles avec la mise en mémoire tampon interne de std::osyncstream, et pourquoi un mauvais usage ramène-t-il les performances à des niveaux similaires à ceux des mutex ?
Beaucoup de candidats pensent que std::flush écrit immédiatement vers le périphérique sous-jacent. Dans std::osyncstream, std::flush déclenche le syncbuf interne pour se préparer à l'émission mais n'appelle pas emit() lui-même ; il ne fait que définir l'état emit_on_flush. Si un utilisateur appelle emit() manuellement après chaque insertion (imitant la mise en mémoire tampon unitaire), il force le verrouillage par message, contrecarrant l'optimisation de regroupement. L'efficacité repose sur le regroupement de plusieurs insertions en un seul appel emit() à la sortie de portée.
Quelle contrainte de durée lie le std::streambuf enveloppé au std::osyncstream, et quel comportement indéfini se produit-il si le tampon enveloppé est détruit avant emit() ?
std::osyncstream stocke un pointeur vers le std::streambuf enveloppé, pas sa propriété. Si vous créez un std::ostringstream temporaire, passez son rdbuf() à std::osyncstream, et que l'ostringstream sort du scope avant le osyncstream, les appels emit() suivants déréférencent un pointeur périmé. Les candidats supposent souvent un comptage de références ou que le osyncstream copie le tampon. La norme impose au programmeur de s'assurer que le streambuf enveloppé survive au syncstream, de manière similaire à comment std::string_view dépend du stockage de chaîne sous-jacent.