問題タブ [boost-thread]

私たちは非常に多くのバックグラウンド処理を行う iPad アプリを作成していますが、そのすべてが一連の C++ ライブラリで作成されています。これらのライブラリは Linux、Mac、および Windows で正常に動作しますが、iPad ではデバッグ ビルドでのみ動作します。

リリース ビルドでは、最初のサブスレッドがスピンアップされているときに、実際には開始されないか、メイン スレッドが続行できるように十分な処理が行われていないように見えます (リリースビルドでブレークポイントを使用するという通常の問題が原因で、スレッドが実際に開始されているかどうかはデバッガー)。

デバッガーを見ると、メイン スレッドが存在しますboost::thread::start_thread(実際には 内にありboost::detail::yieldますboost::detail::spin_lock::lock)。

CPU は 100% ではないため、スピン ロックが新しいスレッドの作成を妨げているようには見えません。

Boost 1.42 と Boost 1.44 の両方を試しましたが、どちらも同じように動作します。iOS 3.2 と 4.2 の両方がリリース ビルドで失敗します。

何が間違っている可能性がありますか、またはこれは既知の機能しない構成ですか?

というわけで、こんな状況です。wait()受信メッセージをブロックして待機する関数を使用して、プロセス間通信を行う C++ ライブラリがあります。問題は、指定された時間内にメッセージが受信されない場合にステータス値を返す、時間指定の待機が必要なことです。

最も洗練された解決策は、おそらくライブラリを書き直して、その API に時限待機を追加することですが、この質問のために、それは実現可能ではないと仮定します。（実際には難しそうなので、他にどんな選択肢があるのか​​知りたいです。）

疑似コードでビジー待機ループを使用してこれを行う方法は次のとおりです。

ただし、プロセッサ サイクルを消費するビジーな待機は望ましくありません。また、プロセッサの負荷を回避するためにループに呼び出しを追加したくありませんsleep()。これは、応答が遅くなることを意味します。適切な種類のブロックと割り込みでこれを行うものが必要です。より良い解決策にスレッド化が含まれる場合 (可能性が高いと思われます)、既に を使用しているboost::threadので、それを使用することをお勧めします。

これはかなり一般的なパターンであるため、明確な「ベストプラクティス」の正しい答えがあるような状況のように思われるため、この質問を投稿しています。それを行う正しい方法は何ですか？

追加する編集：ここでの私の懸念の大部分は、これがプログラム内のパフォーマンスが重要であり、競合状態やメモリリークを回避するために重要な場所にあるということです。したがって、「2 つのスレッドと 1 つのタイマーを使用する」というアドバイスは役に立ちますが、実際にそれを安全かつ正しい方法で実装する方法を見つけようとしているところが残っています。作ったことすら知りません。したがって、いくつかの実際のサンプルコードは本当にありがたいです!

また、マルチスレッド ソリューションについて懸念があります。 ? 最初のスレッドの時限待機が返されることはわかっており、応答が発生せず、処理が続行されることがわかりますが、その後、ブロックされた状態で永遠に座っているスレッドを「リーク」しましたか? それを回避する方法はありますか？(それを回避し、2 番目のスレッドのメモリのリークを回避する方法はありますか?) ブロッキング呼び出しが返されない場合にリークを回避するために必要なものに対する完全な解決策が必要です。

下記のIServiceクラスに関するフィードバックをお願いします。私の知る限り、このタイプのクラスは「アクティブオブジェクト」パターンに関連しています。関連する用語を誤って使用した場合は、失礼/訂正してください。基本的に、このアクティブオブジェクトクラスを使用するクラスは、イベントループを制御するstartメソッドとstopメソッドを提供する必要があるという考え方です。このイベントループは、whileループまたはboostasioなどで実装できます。

このクラスは、イベントを新しいスレッド内または新しいスレッドで処理できるように、非ブロッキング方式で新しいスレッドを開始する役割を果たします。また、クリーンアップに関連するすべてのコードを処理する必要があります。私は最初に、サブクラスがイベントループを制御するメソッドのオーバーライドを担当するオブジェクト指向アプローチを試しましたが、クリーンアップは面倒でした。デストラクタでstopメソッドを呼び出すと、呼び出し元のクラスが手動で呼び出していない場合に、純粋仮想関数呼び出しが発生しました。停止メソッド。テンプレート化されたソリューションは、はるかにクリーンなようです。

このクラスは次のように使用できます。

今私の特定の質問に：

1）ブースト条件変数の使用は正しいですか？私にはちょっとしたハックのように思えます。スレッドが起動するのを待ちたかったので、条件変数を待ちました。次に、新しいスレッドがmainメソッドで起動されたら、同じ条件変数を再度待機して、最初のスレッドが続行できるようにします。次に、最初のスレッドのstartメソッドが終了すると、新しいスレッドを続行できます。これでいい？

2）OSがスレッドを正常に起動できない場合はありますか？私はこれが起こる可能性があることをどこかで読んだことを覚えています。これが可能であれば、（startメソッドでコメント化されているように）条件変数で時間指定待機を行う必要がありますか？

3）テンプレート化されたクラスがstopメソッドを「正しく」実装できなかったことを認識しています。つまり、イベントループの停止に失敗した場合、コードは結合（停止またはデストラクタのいずれか）でブロックされますが、方法がわかりません。このあたり。startメソッドとstopメソッドが正しく実装されていることを確認するのは、クラスのユーザー次第だと思いますか？

4）他の設計ミス、改善などをいただければ幸いです。

ありがとう！

私は自分のアプリケーションでこの問題に苦労していたので、簡単なコード スニペットで問題を再現しようとしました。

Boost 1.44 と mingw32-g++ バージョン 4.4.1 を使用しています。Windows XP の場合

次のプログラムの期待される結果は次のとおりです。

しかし、実際にはこれを行うこともあれば、「未処理の win32 例外...」(Just In Time デバッガーを使用) と詳細にクラッシュすることもあり、サイレントにクラッシュすることもあります。

だから私はなぜこれを行うのか途方に暮れています。

try...catch ブロックを削除すると、プログラムは問題なく実行されます。

コードは次のとおりです。

非メインスレッドで io_service インスタンスを管理することは違法ですか? または、私は盲目的に明らかに間違ったことをしましたか!?

どんな助けにも感謝します！

ありがとう

現在、リアルタイムグラフィックスアプリケーションのレンダリング部分にプロデューサーコンシューマーモデルを使用しています。コンシューマーは、キュー内のデータを継続的に検索します（無限ループ）。ただし、これによりシミュレーションがメインループの同期から外れる可能性があるのではないかと心配しています。これは、高速生産者と低速消費者の問題だと思います。シミュレーションが一定の時間に制限されているという事実によってさらに複雑になっています。

質問-これをすべてバランスを保ち、消費者が終了するのに十分な時間を確保するだけでなく、現在のフレームのレンダリングが完了する前にシミュレーションが次のフレームに移動しないようにするための最良の方法は何ですか（または少なくともこれを検出して次のフレームのレンダリングをスキップする-またはレンダリングされている現在のフレームを中断する）現在、各コンシューマーが終了した後、中断して参加しています

2番目の質問：以下のコードを見ると、現在、キューにレンダリングジョブを追加した後、割り込みと参加を呼び出していることがわかります。これにより、スレッドは操作を完了し、割り込みに応答する必要があります。終わった時に。その後、interrupt_allとjoin_allが呼び出された後、スレッドプール内のスレッドを再利用するにはどうすればよいですか？（つまり、drawNextFrameを再度呼び出す場合）

プロデューサーは実行のメインスレッドの一部です（これは何にも影響しないと思います）

コンシューマークラスを確認する必要がある場合は、以下を参照してください。

私はこれを簡単で素早く消化できるようにしようとしました、お時間をいただきありがとうございます

C ++でlibcurlを使用しており、 Boost.Threadcurl_easy_performを使用してUIとは別のスレッドで呼び出しています。

メインUIには、完全に応答したいキャンセルボタンがあります（つまり、ユーザーがクリックすると、すぐに反応するはずです）。（このshould_cancel質問のように）アトミック変数を読み取るように設定された読み取り、書き込み、および進行状況のコールバックがありますが、2つの問題があります。

1. 多くの場合、キャンセルが押されてからカール操作が完了するまで、非常に小さな（ただし目立つ）遅延があります。

2. 時折、非常に長い（時には途方もない）遅延があります。この場合、次のいずれかです。

   a。進行状況、読み取り、および書き込みのコールバックは、単に長い間呼び出されないか、または

   b。progressコールバックが呼び出され、ゼロ以外の値が返されます（つまり、終了する必要があります）が、curl操作がしばらく完了しません（実際、progress関数がその間に再度呼び出されます！）

それで：

1. なぜ長い遅延が発生するのですか（特にprogress関数を呼び出さずに）？
2. キャンセルボタンが正しく反応するようにするには、代わりに何をすればよいですか？

1つの可能性は、キャンセル操作が成功したことをUIに通知することですが、キャンセルされるまでバックグラウンドでカールスレッドを実行し続けます。これに伴う問題（私は思う）はshould_cancel、操作が開始されたダイアログボックスにスコープされるのではなく、変数が強制的にグローバルになることです。

C++ プロジェクトでスレッドをサポートするために、boost::thread ライブラリ (V1.44) を使用しています。

ユーザーは、独自のスレッドで実行されているテスト ループの実行を無制限に一時停止し、いつでも再開できる必要があります。

Windowsでは、このように解決しました

これは問題なく機能しますが、無制限の中断の正しい値を知っていると便利です。

プログラムの Linux 版の実装を開始しましたが、コンパイラ エラーが発生するという問題に遭遇しました。

エラー:interruptible_waitのメンバーではありませんboost::this_thread

質問: boost::thread を無制限に (ユーザーが再開するまで) 一時停止する良い方法は何ですか?

どうもありがとうございました

ブースト C++ によって作成されたスレッドから NSOpenPanel を呼び出しています。

パネルが不規則に動作し、マウスにうまく反応しません。つまり、最上位のコンボ ボックスをクリックすると反応が改善されるのに、オブジェクトをクリックしても何も起こらないことがあります。

独自のループを実行する必要がある runModalForDirectory を実行しています。

メインスレッドでパネルを表示するために performSelectorOnMainThread を実行する別の objc クラスも作成しましたが、それでも動作は同じです。

また、waitUntilDone:NO を試してみましたが、どちらも役に立たない CFRunLoopRunInMode を実行しています。

最近、私はpdf DesigningMTprogramsを読んでいます。これは、オブジェクトがスコープ外になる前に、ユーザーがC++0xdetach()のクラスのオブジェクトを明示的に呼び出さなければならないことを説明しています。std::thread呼び出さない場合はstd::terminate()呼び出され、アプリケーションは停止します。

私は通常boost::thread、C++でのスレッド化に使用します。boost::thread私が間違っているが、オブジェクトがスコープから外れると自動的に切り離される場合は、私を訂正してください。

ブーストアプローチはRAIIの原則に従いますが、stdは従​​わないようです。

これには特別な理由があるかどうか知っていますか？

gdb でのデバッグは私にとって不便なので、code::blocks が提供する優れたデバッグ インターフェイスを楽しんでいます。これらのフラグが必要な領域 (もちろん、タイトルにあるもの) にプロジェクトを移動したので、もう code::blocks でコンパイルできないことがわかりました :/.