質問の歴史
C++20以前、C++標準は手動同期なしで共有ストリームへのフォーマットされた出力のためのスレッドセーフな機能を提供していませんでした。std::coutはsync_with_stdioを介してCストリームと同期することが保証されていましたが、これによりバッファリングが防止され、深刻なパフォーマンスの低下を引き起こしました。開発者は通常、各挿入の周りにstd::mutexをラップしていましたが、これはスレッドを完全に直列化し、1つのコードパスでもロックを忘れるとインタリーブから守ることができませんでした。出力を原子的にバッチ処理する高レベルの抽象化が求められるようになりました。
問題
標準ストリーム挿入操作は原子的ではありません。複雑な型に対する単一のoperator<<呼び出しは、基礎となるstd::streambufに対して複数のsputcまたはsputn呼び出しをトリガーする可能性があり、同時実行スレッドはこの詳細なレベルで文字をインタリーブされる可能性があります。既存の回避策として、std::stringstreamに続いてロックされた出力を行う方法は、全バッファの追加コピーを必要としました。手動ロックはボイラープレートを追加し、例外が発生する前にミューテックスアンロックされるとデッドロックのリスクがありました。
解決策
C++20はstd::basic_osyncstream（char用にエイリアスされたstd::osyncstream）を導入しました。これは、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コミットレコードを書き込む必要がありました。各レコードにはトランザクションID、タイムスタンプ、およびステータスフラグが含まれていました。原子的なエミッションがなければ、異なるスレッドからの波括弧や引用符が混ざり合い、腐敗したJSONが生成され、下流の分析パイプラインが解析できなくなり、夜間バッチジョブが失敗する原因となりました。
検討された解決策の1つは、同時読み取りを許可するが排他書き込みを行うグローバルstd::shared_mutexでした。利点：おなじみの同期パターン。欠点：ライターはJSONフォーマットの全期間にわたって依然として直列化され、コミットストーム中の高い競合によって待機時間のスパイクが発生し、ロックを保持しているスレッドがアンロックの前に例外をスローした場合はデッドロックのリスクがありました。
別のアプローチでは、スレッドごとのログファイルがバックグラウンドスレッドによってマージされました。利点：書き込みパスにおける競合がゼロ;トランザクション処理中のロックは必要ありません。欠点：複雑なログローテーションとファイル管理;スレッド間の時間的順序の喪失;複数のファイルハンドルからのディスクI/Oの増加;マージスレッドがクラッシュした場合にログが失われる可能性がありました。
チームはstd::osyncstreamを採用しました。各トランザクションスコープは、共有監査std::ofstreamをラップするローカルなstd::osyncstreamを作成します。JSONは内部バッファで構築され、スコープ終了時に原子的にエミットされます。これにより、ロック保持時間がミリ秒（JSONフォーマット時間）からマイクロ秒（バッファコピー）に短縮され、完全に腐敗を排除し、**emit()**が基礎となるファイルバッファへのアクセスを直列化するため、年代順も保持されました。
結果：システムはログの腐敗なしで毎秒10万件以上のコミットを持続し、レコードが完全かつ順序を維持しているため、デバッグが実行可能になりました。
なぜstd::osyncstreamのデストラクタはemit()を無条件に呼び出し、基礎となるストリームがスローした場合の例外安全性への影響は何ですか？
デストラクタは、バッファリングされたデータが失われないことを確保するためにemit()を呼び出します。もしemit()がスローした場合（例：ディスク満杯）、デストラクタは暗黙的にnoexceptであるため、std::terminateが即座に呼び出されます。候補者はしばしば、例外が伝搬するか、バッファが静かに破棄されると考えています。正しい詳細は、std::basic_syncbufがemit_on_flushフラグとエラーステートを提供し、**get_wrapped()**を介してアクセスできることですが、デストラクタはデータの静かに喪失することやデストラクタからの例外漏出よりもプログラムの終了を優先します。
明示的なフラッシュ操作（std::flushまたはstd::endl）は、std::osyncstreamの内部バッファリングとどのように相互作用し、なぜ誤用がミューテックスのようなレベルにパフォーマンスを戻すのですか？
多くの候補者は、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が基礎となる文字列ストレージに依存するのと同様です。