Boost.Signals はスレッドセーフではないことを複数の場所で読みましたが、詳細はわかりませんでした。この単純な引用は、それほど多くを語っていません。現在、ほとんどのアプリケーションにはスレッドがあります。シングル スレッドにしようとしても、一部のライブラリはスレッドを使用する場合があります (libsdl など)。
他のスレッドがスロットにアクセスしないという実装の問題はないと思います。したがって、少なくともこの意味ではスレッドセーフです。
しかし、正確には何が機能し、何が機能しないのでしょうか? 同時にアクセスしない限り、複数のスレッドから使用することはできますか? つまり、スロットの周りに独自のミューテックスを構築した場合はどうなりますか?
それとも、スロットを作成したスレッドでのみスロットを使用する必要がありますか? または、初めて使用した場所はどこですか？
私もそれがあまりにも明確だとは思わないし、図書館の評論家の一人がここで言った：
また、「スレッド」という単語が 3 回しか使われていないことも気に入りません。Boost.signals2 は、「スレッドセーフなシグナル」ライブラリになりたいと考えています。したがって、その領域に関するいくつかの詳細と特により多くの例をユーザーに提供する必要があります。
それを理解する 1 つの方法は、ソースにアクセスして、保護するために _mutex / lock() を使用しているものを確認することです。次に、それらの呼び出しがなかったらどうなるか想像してみてください。:)
私が収集できることから、「あるスレッドが接続または切断を行っている場合、それらのシグナルに接続されたスロットを反復処理している別のスレッドがクラッシュすることはありません」などの単純なことを保証しています。C ランタイム ライブラリのスレッド セーフ バージョンを使用すると、2 つのスレッドがprintf同時に有効な呼び出しを行ってもクラッシュしないことが保証されるのと似ています。 (得られる出力が意味をなすとは言いません。高次のセマンティクスについては、依然として責任があります。)
特定のスロットのコードが実行されるスレッドがターゲット スロットの「スレッド アフィニティ」に基づいている Qt のようには見えません (つまり、シグナルを発行すると、多くの異なるスレッドのスロットが並列実行される可能性があります)。しかし、私はそれをサポートしていないと思うので、boost::signal「コンバイナー」はこのようなことを行うことができます.
私が見た問題の 1 つは、別のスレッドがシグナルを送信しているときに、あるスレッドが接続または切断できることです。
シグナルを簡単にラップし、ミューテックスを使用して呼び出しを接続できます。ただし、接続をラップすることは自明ではありません。(connect は、切断に使用できる接続を返します)。