問題タブ [boost-thread]

Boostライブラリにもpthreadがあることがわかりましたが、それはposix pthreadと同じものですか？

sslsniffここでRHEL5.2システムを構築しようとしています。sslsniffRHELでコンパイルすると、libboostパッケージ（rpmforgeなどのリポジトリから）を使用した場合とlibboostソースからコンパイルした場合（成功したように見えます）に同じエラーが発生しました。これを新しいシステムでも試しました（以前の/失敗した/ガベージのインストールlibboostなどはありません）。 ）。

もっとありますが、ポストの長さには制限があると思います。

それらのほとんどは関連しているように見えるので、私はリンカーコマンドboost::systemに追加してさらに進んだ：-lboost_system

これで、エラーはとに関連しboost::detailますboost::filesystem::detail。

ブースト1.35と1.42（最新）を使ってみました。

私自身のUbuntuシステムでは、Ubuntuリポジトリからライブラリをインストールし、sslsniffを正常にコンパイル+リンクすることができました。

前もって感謝します。

ブーストスレッドライブラリには、スレッド固有の（ローカル）ストレージの抽象化があります。ソースコードをざっと見てみましたが、TSS機能は、boost :: threadから作成された天気に関係なく、既存のスレッドを使用するアプリケーションで使用できるようです。つまり、特定のコールバックがカーネルに登録されていることを意味します。スレッドまたはプロセスがスコープ外になるときに、TSSオブジェクトのデストラクタを呼び出す可能性のあるコールバック関数をフックします。これらのコールバックを見つけました。

さまざまなWebサーバーのワーカースレッド内にOpenSSLからHMAC_CTXをキャッシュする必要があります（私がやろうとしていることについては、この詳細な質問を参照してください）。そのため、スレッドの存続期間（Web）を制御しません。 -サーバーは行います。したがって、boost::threadによって作成されていないスレッドでTSS機能を使用します。

キャッシングロジックの実装を開始する前に、仮定を検証したかったのですが、ロジックに欠陥はありますか？

boost / thread / tss.hppがインスタンスであるポータブルスレッド固有のストレージ参照/IDメカニズムには、それ自体に固有のキーを生成する方法が必要です。このキーはスレッドのスコープ内で一意であり、その後、参照するオブジェクトを取得するために使用されます。このメカニズムは、スレッドニュートラルな方法で記述されたコードで使用されます。

ブーストはこの概念の移植可能な例であるため、そのようなメカニズムはどのように具体的に機能しますか？

ListenerThreadリモートサーバーによってブロードキャストされた情報をリッスンするソケットを持つ別のスレッドがあります。これは、開発する必要がある 1 つのクラスのコンストラクターで作成されます。

要件により、別のスレッドが開始されたら、メイン スレッドでのブロック機能を回避する必要があります。クラスのデストラクタを呼び出す段階になると、リスナー スレッドで結合を実行できないため、できることはそれを KILL することだけです。

私の質問は次のとおりです。

1. スレッドに渡された関数によって割り当てられたネットワークリソースはどうなりますか? ソケットが適切に閉じられているか、保留中の何かがある可能性がありますか? （ここが一番心配）

2. この手順は十分に高速ですか?つまり、すぐに中断するようにスレッドが強制終了されますか?

3. 私は Linux を使用しています ...保留中のネットワーク リソースがないこと、またはオペレーティング システムで問題が発生していないことを確認するために、どのコマンドまたは何を確認できますか

あなたの助けに感謝します

よろしく MNSTN

注: C++ で boost::thread を使用しています

特定のシステムのシミュレーションを実行するプログラムを C++ で作成しています。タイムステップごとに、実行の大部分は 1 つのループで占められています。幸いなことに、これは非常に並列であるため、Boost Threads を使用して並列化することにしました (2 コアのマシンで実行しています)。ロックがないため、シリアル バージョンの 2 倍近くの高速化が期待できます。ただし、スピードアップはまったくないことがわかりました。

ループの並列バージョンを次のように実装しました。

• 2 つのスレッドを起動します (バリアでブロックされています)。

• その後、各スレッドは以下を実行します。

  • グローバル カウンターをアトミックにフェッチしてインクリメントします。
  • そのインデックスでパーティクルを取得します。
  • その粒子で計算を実行し、結果を別の配列に格納します
  • ジョブ終了バリアで待機

• メイン スレッドはジョブ終了バリアで待機します。

このアプローチを使用したのは、適切な負荷分散を提供する必要があるためです (各計算にかかる時間が異なる場合があるため)。この速度低下の原因は何なのか、非常に興味があります。アトミック変数は高速であるといつも読んでいますが、今ではパフォーマンス コストがあるのか​​どうか疑問に思い始めています。

何を探すべきか、またはヒントがあれば、本当に感謝します。私は 1 週間頭を悩ませてきましたが、プロファイリングではあまり明らかになりませんでした。

編集：問題は解決しました！ この問題をどのように解決したかを詳しく説明します。再度 gprof を使用しましたが、今回は最適化フラグ (-O3) なしでコンパイルしました。すぐに、プロファイラーは、個々の粒子の計算を実行する関数に信じられないほどの時間を費やしていることを示しました。これは、シリアル バージョンよりもはるかに長い時間です。

この関数は仮想であり、多態的にアクセスされます。vtable を介してではなく直接アクセスするようにコードを変更したところ、ほら、並列バージョンではほぼ 2 倍のスピードアップが実現しました。シリアル版での同じ変更はほとんど効果がありませんでした。

なぜそうなのかはよくわかりませんが、誰かが知っていれば興味があります！

ポスターの皆様ありがとうございました。皆さんはある程度助けてくれました。1 つの答えを受け入れるのは非常に難しいでしょう。

私は C++ boost::thread ライブラリを使用しています。これは、私の場合は pthreads を使用していることを意味します。公式には、ミューテックスはそれをロックしている同じスレッドからロック解除する必要があり、あるスレッドでロックしてから別のスレッドでロック解除できるという効果が必要です。これを実現するには多くの方法があります。1 つの可能性は、この動作を許可する新しいミューテックス クラスを作成することです。

例えば：

あるスレッドが lock() を呼び出し、別のスレッドが unlock() を呼び出した場合、この最初のスレッドが、待機している他のスレッドより先にロックを取得する可能性があるため、上記のコードは FIFO アクセスを保証しないことを指摘しておく必要があります。(考えてみると、boost::thread のドキュメントでは、ミューテックスまたは条件変数のいずれに対しても明示的なスケジューリング保証が行われていないようです)。しかし、今はそれ (およびその他のバグ) を無視しましょう。

私の質問は、もし私がこの道を進むことにした場合、そのようなミューテックスをブースト ロック可能コンセプトのモデルとして使用できるかどうかです。 boost::unique_lock< inter_thread_mutex > たとえば、 RAII スタイルのアクセスに を使用し、このロックをboost::condition_variable_any.wait()などに渡すと、何か問題が発生します。

一方では、なぜそうしないのかわかりません。一方、「なぜだかわからない」というのは、通常、何かがうまくいくかどうかを判断するための非常に悪い方法です。

私が尋ねる理由は、RAII ロックや条件変数などのラッパー クラスを作成する必要があることが判明した場合は、同じ効果を達成するための別の方法を見つけたいからです。

編集:私が望む動作の種類は、基本的に次のとおりです。オブジェクトがあり、変更するたびにロックする必要があります。オブジェクトを 1 つのスレッドからロックし、そのオブジェクトに対して何らかの作業を行いたいと考えています。次に、別のワーカー スレッドに作業を完了するように指示している間、オブジェクトをロックしたままにします。そのため、ワーカー スレッドが終了している間に、最初のスレッドが続行して別の処理を行うことができます。ワーカー スレッドが完了すると、mutex のロックが解除されます。

そして、スレッド 1 が作業を開始してからスレッド 2 が作業を完了するまでの間、他の誰もミューテックス ロックを取得できないように、トランジションをスムーズにしたいと考えています。

inter_thread_mutex のようなものは機能するように見え、プログラムは通常のミューテックスであるかのように対話することもできます。だから、それはきれいな解決策のようです。より良い解決策があれば、それも聞いてうれしいです。

もう一度編集: 最初にロックが必要な理由は、複数のマスター スレッドがあり、共有オブジェクトに無効な方法で同時にアクセスするのを防ぐためにロックが存在するためです。そのため、コードはマスター スレッド レベルでループ レベルのロックのない操作の順序付けを既に使用しています。また、元の実装では、ワーカー スレッドはなく、ミューテックスは通常のコーシャ ミューテックスでした。

inter_thread_thingy は、主に応答時間を改善するための最適化として登場しました。多くの場合、操作 A の「最初の部分」が操作 B の「最初の部分」の前に発生することを保証するのに十分でした。馬鹿げた例として、オブジェクト 1 をパンチして目を黒くしたとします。次に、オブジェクト 1 の内部構造を変更して、すべての組織損傷を反映するように指示します。オブジェクト 2 のパンチに移る前に、組織の損傷を待ちたくありません。ただし、同じ操作の一部として組織の損傷を発生させたいと考えています。たとえば、当面の間、組織の損傷を無効な操作にするような方法で、他のスレッドがオブジェクトを再構成することは望ましくありません。(はい、この例は多くの点で不完全です。いいえ、私はゲームに取り組んでいません)

そのため、オブジェクトの所有権をワーカー スレッドに渡して操作を完了することができるモデルに変更を加えましたが、実際には非常にうまく機能します。すべての操作が完了するのを待つ必要がないため、各マスター スレッドはより多くの操作を実行できます。また、マスター スレッド レベルでのイベント シーケンスは依然としてループベースであるため、高度なマスター スレッド操作を簡単に記述できます。これは、操作が完了したという前提に基づくことができるためです (より正確には、重要な "対応する関数呼び出しが返されたときに、シーケンス ロジックが依存する最初の部分" が完了します。

最後に、すべてを機能させるために必要な同期をカプセル化するために、RAII とブースト ロックを使用して inter_thread ミューテックス/セマフォを使用するとよいと思いました。

ブースト ロック可能の概念 (つまり、lock(); unlock(); try_lock();など) をモデル化するインターフェイスを使用して C++ セマフォ クラスを作成するとします。そのようなオブジェクトへの RAII アクセスにブースト ロックを使用することは安全ですか、または推奨されますか? 言い換えれば、ブースト ロック (および/またはブースト スレッド ライブラリの他の関連部分) は、Lockable の概念が、同じスレッドからロックおよびロック解除されるミューテックスのようなオブジェクトによってのみモデル化されると想定していますか?

私の推測では、Lockable のモデルとしてセマフォを使用しても問題ないはずです。いくつかのブースト ソースを閲覧しましたが、問題ないようです。ロックは、this_thread などへの明示的な参照を格納していないようです。さらに、Lockable の概念には のような機能はありませんwhichThreadOwnsMe()。boost::unique_lock<MySemaphore>また、への参照を渡すことさえできるはずboost::condition_variable_any::waitです。ただし、ドキュメントは要件について明確に明確ではありません。

私が何を意味するかを説明するために、次の行に沿ってベアボーン バイナリ セマフォ クラスを考えてみましょう。

ここで、オブジェクトまたはグローバルのどこかに、私が持っているとします。

RAII を使用してロックおよびロック解除したい。また、あるスレッドから別のスレッドにロックの所有権を「渡す」ことができるようにしたいと考えています。たとえば、私が実行する1つのスレッドで

別のスレッドが次のようなものを実行している間

私がこれを行っている理由は、最初のスレッドが実行されてから 2 番目のスレッドが実行さsemれるまでの間、他の誰かがロックを取得できないようにするためです。基本的に、1 つのタスクを 2 つの部分に分割しています。タスクを分割する理由は、(1) タスクの最初の部分をできるだけ早く開始したい、(2) doTask() が戻る前に最初の部分が完了していることを保証したい、 (3) タスクの 2 番目の、より時間のかかる部分を、マスター スレッドによって開始されたタスクの完了を待機しているスレーブ スレッドのプールから選択された別のスレッドによって完了させたい。doSomeWorkWithSharedObject()doMoreWorkWithSameSharedObject()

注: 最近、同じ質問 (一種) をここに投稿しましたModeling boost::Lockable with semaphore rather than mutex (以前のタイトル: Unlocking a mutex from a different thread) が、mutex とセマフォを混同したため、ブースト ロックの使用に関する質問本当に対処されませんでした。

一部の C++ オブジェクトにはコピー コンストラクターがなく、ムーブ コンストラクターがあります。たとえば、boost::promise です。移動コンストラクターを使用してこれらのオブジェクトをバインドするにはどうすればよいですか?

以下のboost::threadプログラムの問題点をmwに教えてください

};

}

エラーメッセージが表示されます：エラー：非クラスタイプの「thr1」のメンバー「join」のリクエスト「boost :: thread（）（A（）（））」BoostThread2.cpp：30：エラー：リクエスト非クラスタイプの「thr2」のメンバー「join」の場合「boost::thread（）（A（）（））」