問題タブ [boost-signals2]

オブジェクト指向の関数ポインターを C++ で実装したいと考えています (C# のデリゲートに相当)。

最終クラスのプレースホルダーとして「MagicFunctionPainter」を使用するサンプル コードを作成しました。

std::function または Boost::Signals2 はそれをサポートしていますか? そのケースをサポートする他のライブラリはありますか?

前もって感謝します！

初めてマルチスレッドを掘り下げていると言って、これを序文にします。並行性と同期に関する多くの資料を読んでも、与えられた要件に対する解決策がすぐには見つかりません。

C++11 と Boost を使用して、ワーカー スレッドからメイン スレッドにデータを送信する方法を見つけようとしています。ワーカー スレッドは、アプリケーションの開始時に生成され、ロック フリー キューを継続的に監視します。オブジェクトは、さまざまな間隔でこのキューに入力されます。この部分は機能しています。

データが利用可能になると、メイン スレッドで処理する必要があります。これは、別のシグナルがワーカー スレッド上にないアプリケーションの残りの部分に送信されるためです。これは私が問題を抱えているものです。

ワーカー スレッドが完了するまで、ミューテックスまたは条件変数を介してメイン スレッドをブロックする必要がある場合、どのように応答性が向上しますか? データにアクセスできるように、単一のスレッドのままにしておくこともできます。ここで何かが欠けているに違いありません。

Boost::Asio が最適だと考えて、いくつかの質問を投稿しました。スレッド間でシグナルとデータを送信する方法の例がありますが、応答が示すように、物事はすぐに過度に複雑になり、完全には機能しません。

別のスレッドで作業を投稿するときに、シグナルを boost::asio::io_service に接続する方法は?

Boost::Asio と Main/Workers スレッド - 作業を投稿する前にイベント ループを開始できますか?

何人かの同僚と話した後、1 つの入力と 1 つの出力の 2 つのキューを使用することが提案されました。これは共有スペースにあり、出力キューはワーカー スレッドによって取り込まれます。ワーカー スレッドは常に実行されますが、おそらくアプリケーション レベルで、保留中のタスクがあるかどうかを確認するためにメイン スレッドに強制的に出力キューを調べるタイマーが必要です。

どこに注意を向けるべきかについてのアイデアはありますか? 私がやろうとしていることに対してうまくいくかもしれないテクニックや戦略はありますか? 次にタイマーを見ていきます。

ありがとう。

編集:これは、シミュレーション結果を後処理するプラグイン システムの製品コードです。可能な限り最初に C++11 を使用し、次に Boost を使用しています。Boost の lockfree::queue を使用しています。アプリケーションは 1 つのスレッドで必要なことを実行していますが、現在、パフォーマンスの問題があることがわかっている場所を最適化しようとしています (この場合、別のライブラリを介して行われている計算)。メイン スレッドには、データベース アクセスを含む多くの責任があります。そのため、ワーカー スレッドが実際に行うことを制限したいと考えています。

更新: std::thread を使用して、Boost lock::free キューを検査し、配置されたタスクを処理するワーカー スレッドを起動することにすでに成功しています。問題が発生しているのは、@Pressacco の応答のステップ 5 です。単純にワーカーの終了を待つのではなく、ワーカー スレッドが終了したときにメイン スレッドに値を返し、メイン スレッドに通知する例はありますか?

私は現在、ブースト信号を別のクラスに送信するモジュールを作成する必要がある C++ アプリケーションに取り組んでいます。アプリケーションの基礎として Document-View の例を使用しています ( http://www.boost.org/doc/libs/1_55_0/doc/html/signals2/tutorial.html#signals2.tutorial.document-view ) 、しかし、エラーが発生し続けます:

これは私を完全に困惑させました-エラーは実際にどこで発生しますか?

ビルドログは次のとおりです。

私の主な機能はかなり単純です。GUI、GUI と通信するためのモデル (TrialModel)、500 ミリ秒ごとに +1 をカウントする単純なロジック、およびロジックからブースト信号 2 ライブラリを介してアクセスされるアウトバウンド ロジック アダプターを構築します。

logic クラスは、1 つの引数 (整数) とスレッドとして機能する operator() を持つシグナルを定義します。

TrialLogic.h :

そしてコード自体：

そして最後に、信号を受信するアダプター -

最初の検査から、間違ったことは何も見つかりませんでしたが、明らかにコードに重大な欠陥があります。私は実際にブースト機能を使用しておらず、システムを一緒にバインドしようとする前に問題なく動作していたため、GUI 側にも問題はないと確信しています。

助言がありますか？

関数への呼び出しの実行時間を追跡するヘルパー関数で std::bind() またはラムダの結果をラップしたいと思います。任意の数のパラメーター (およびクラス メソッド) で動作し、c++11 と互換性のある一般化されたソリューションが必要です。

私の意図は、ラップされた関数を受け取り、それを boost::signals2::signal に渡すことです。そのため、結果の関数オブジェクトは元の関数とシグネチャが同一である必要があります。

私は基本的に、Wrapper次のように機能する魔法のクラスまたは関数を探しています。

これは、42 を印刷するのにかかった時間を計測します。

ありがとう！

VS2013 の次のコンパイラ警告メッセージから:

CL : 警告 : Boost.Signals はメンテナンスされなくなり、非推奨になりました。Boost.Signals2 に切り替えてください。この警告メッセージを無効にするには、 を定義しますBOOST_SIGNALS_NO_DEPRECATION_WARNING。

boost::signalsコードを からにアップグレードしましたboost::signals2。

現在、さらに多くの醜い警告が延々と続いていますが、これはほんの始まりにすぎません。

この以前に尋ねられた質問と他の多くの質問を見てきましたが、提案された唯一の解決策は警告を無効にすることです。ただし、それは大きなハンマーのアプローチです。上記の投稿で @heavy-rocker-dude が指摘したように、これは最も些細なブーストHello World の例でも発生します(クールではありません)。

警告を損なうことなく実際に問題を解決するソリューションを提案できる人はいますか?

シグナル ハンドラを使用してイベントをトリガーすると、 ( boost.msm) ステート マシンが「ロールバック」しているように見えます。ただし、直接呼び出しを使用してイベントをトリガーすると、ステート マシンは正しく動作します。

boost のドキュメントを参照して Web を検索したところ、すべての例でイベント トリガーに直接呼び出しが使用されているようです。SOも検索しましたが、このトピックに対処するものは見つかりませんでした。

開発チームが現在使用している既存の「自作」ステート マシン ライブラリを置き換えるのに役立つかどうかを確認するために、ブースト メタ ステート マシン ライブラリを学習中です。

これを機能させるには、シグナル ハンドラー (からのシグナルの処理) からステート マシン イベントをトリガーできる必要がありますboost.signals2。

テストを実行するために単純だが不自然な例を作成し、最初のイベントがトリガーされた後、ステート マシンが (シグナル ハンドラー内で) 状態を正しく (ただし一時的に) 変更したものの、明らかに「ロールした」ことを確認して困惑しました。メインに戻った後。

(process_event への直接呼び出しを使用して) シグナル ハンドラーをバイパスすると、すべてが正しく機能しました。

確かに考案されたテスト ステート マシンは、これを行うように設計されています。

シグナル ハンドラーを使用してこのデザイン (または同様のもの) を機能させ、ステート マシン イベントを正しくトリガーする方法を知りたいです。私は操作する信号しか受信しないため、直接呼び出しを使用することはできません。

以下のテストコードを含めました。main 関数の前半はシグナル ハンドラのトリガーを実行し、main の後半は直接呼び出しのトリガーを実行することに注意してください ( を使用してコンパイルg++ main.cpp -omain' or 'clang++ main.cpp -omain)。

出力は次のとおりです。

参照しやすいように、出力ファイルを後処理して行番号を追加しました。

出力の 01 行目は、ステート マシンが最初の疑似状態から state_a に正しく遷移したことを示しています。

出力の 14 行目は、on_sa_event 関数内でステート マシンが state_a から state_b に正しく遷移したことを示しています。

ただし、17 行目は、メインからテストしたときにステート マシンが state_a に戻ったことを示しています (!)

ステート マシンは、シグナル ハンドラー テストの残りの遷移 (18 行目から 41 行目) の間、state_a のままであり、いくつかの「No Transition」エラー メッセージが表示されます。

直接呼び出しの演習 (出力行 42 ～ 65) の場合、ステート マシンはすべての状態を正しく遷移し、トリガー関数内とメインのとき (トリガー関数呼び出し後) の「現在の状態」に違いはありません。

環境：OS：「Ubuntu 16.04 LTS」

g++ バージョン: (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413

ブースト バージョン: boost_1_60_0

boost::signals2 を使用していますが、接続管理の問題があります。scoped_connections をリストに保存していますが、これは後で削除されます。しかし、関連付けられたシグナルを所有するオブジェクトが破棄された場合、そのフィールドのいくつかが無効になるため、scoped_connection::disconnect() が異常終了することがわかりました。

クライアント接続:

Manager クラスは、これらの ClientConnections のリストを所有し、定期的に反復して、クライアントへの正当な shared_ptr を取得できないエントリを削除しようとします。私が思っていたように、オブジェクトの有効期限が切れたときに track() が接続を切断しないことを学びました。信号が発火するのを防ぐだけです。クライアントがスコープ外に出ると、scoped_connection は大量の不良メモリを指し示し、disconnect() を実行するとプリフェッチまたはデータの中止が発生します。

この問題を修正できる、見落としていた signal2 API に何かありますか? または、接続管理を再考する必要がありますか? この端からクライアントのシグナルへの接続を維持する必要があるのは奇妙に思えますが、クライアントが消費するストリームが範囲外になる可能性があるため、その場合はマネージャーのスロットをクライアントから切断する必要があります。