0

libboot_*-mt バリアントに対してリンクするかどうか、およびそれらが実際に何に使用されるかについて、少し混乱しています。

Centos 6 でブースト 1.46.0 のカスタム バックポートを使用しています。ビルドにより、/usr/lib64/libboost_thread-mt.so.7 と、他のライブラリの -mt および標準バージョンが生成されます。

スレッドを使用して計算をboost::futureに保存する単体テストプログラムを作成しました。そのテストをリンクするには、-lboost_thread-mt を追加する必要がありました。しかし、-mt バージョンを使用するために他の boost -l 引数を変更する必要はありませんでした。

ブースト サイトのライブラリ ネーミングセクションを読みましたが 、「ライブラリがマルチスレッド サポートを有効にしてビルドされたことを示しています。マルチスレッド サポートなしでビルドされたライブラリは、-mt がないことで識別できます」が実際に何を意味するのかが明確ではありません。

  1. -lboost_thread-mt でリンクする場合、他のライブラリのマルチスレッド対応バージョンに切り替える必要がありますか? そうでない場合、いつ -mt バリアントに対してリンクする必要がありますか?

  2. 必要な場合にのみ -mt バリアントに対して選択的にリンクするための推奨事項はありますか? このプロジェクトは、ビルドに GNU Make を使用します。

  3. -mt バリアントに対して常にリンクすると、パフォーマンスまたは機能上のペナルティはありますか?

4

1 に答える 1

3

「mt」バリアントはthreading=multi、bjam 行に設定するとビルドされます。"mt" オプションの結果の 1 つは、それBOOST_HAS_THREADSが定義されていることです。

もちろん、リンクするすべてのブースト ライブラリは、アプリケーションのスレッドと一致する同じバリアントである必要があります。そうしないと、ODR 違反になる可能性があります。たとえばshared_ptr、ライブラリ A では を使用せずBOOST_HAS_THREADSにコンパイルし、ライブラリ B では を使用してコンパイルするとしBOOST_HAS_THREADSます。この 2 つshared_ptrは、スピンロック クラスの実装がまったく異なります。したがって、shared_ptrlib A から取得して lib B に渡すと、プログラムがクラッシュします。さらに、mt バリアントと非 mt バリアントは異なるヒープを使用する場合があります。

(そうは言っても、BOOST_HAS_THREADS は他のいくつかのマクロに依存し、非 mt バリアントでも定義できることに言及する価値があるため、mt と非 mt を混在させるとうまくいく場合がありますが、これに依存しないでください。)

パフォーマンスのペナルティについては、明らかに、mt バリアントは少し遅くなる可能性があります。

更新: に関する私の仮定はBOOST_HAS_THREADS 間違っているようです。threading=multiそれでも、 Boost ABIに影響するため、mt バリアントと非 mt バリアントを混在させることはお勧めできません。

于 2012-07-18T08:59:59.970 に答える