問題タブ [concurrency-runtime]

クラスConcurrency::unbounded_bufferには、任意の数のメッセージを格納できます。しかし、保留中の (受信されていない) メッセージの数を知る方法は?

私は現在、MicrosoftのConcurrencyRuntimeで非同期エージェントライブラリを使用しています。ウィンドウメッセージ、または作業が終了したことをUIスレッドに通知するその他の手段を使用して、タスクが終了したことを通知する明確な方法をまだ見つけていません。

ウィンドウハンドルとメッセージ値（WM_xxx）をタスクに渡し、タスクを使用PostMessage()してUIスレッドに信号を送ることができることはわかっています。これは私の意見ではやや醜く、エラーの原因です。例外が発生した場合は、UIスレッドに信号を送るcatchハンドラーが必要です。これは簡単に忘れられ、例外条件はあまり頻繁に実行されない可能性があるため、見つけるのは困難です。

ドキュメントでは、データをUIスレッドに戻す方法について説明しています。ウィンドウメッセージは使用しませんが、ポーリング技術を使用します。「割り込み」メソッドが利用可能な場合に、タスクが終了したかどうかをポーリングするタイマーを設定するのはばかげていると思います。

クロスプラットフォームライブラリではないため、これがライブラリに組み込まれていないのは奇妙なことです。私の理解では、Windowsで実行するように設計されており、Windowsのみで実行するように設計されています。

ライブラリで機能を利用できますか、それともこれを手作業でロールする必要がありますか？

私は unbounded_buffer の便利さが気に入っていますが、同時実行ランタイムが何も知らないスレッドでもこのクラスを使用したいと考えています。私のテストでは、うまくいくようです。このアプローチに潜在的な問題はありますか?

ヒープに割り当てられたオブジェクトをdllから渡したい。明らかに、メモリは正しく管理する必要があります。私が考案した次の狡猾なスキームに問題がある人はいますか？

shared_ptrが含まれているオブジェクトの削除機能を隠していることを認識しているので、dllの境界を越えて単独で使用しても問題はありません。

私はMicrosoftConcurrencyRuntime（および一般的な非同期プログラミング）に不慣れであり、それを使用して何ができるか、何ができないかを理解しようとしています。追加された順序でタスクが実行され、前のタスクが終了するまでタスクが開始されないようなタスクグループを作成することは可能ですか？

単一のメンバー関数内で複数のタスクをチェーンするのと比較して、タスクを処理するためのより一般的で発展した方法があるかどうかを理解しようとしています。たとえば、プログラムのさまざまなポイントでリソースを作成するプログラムがあり、リソースが割り当てられる順序が重要であるとします。呼び出されたリソース割り当て関数は、中央のタスクリストの最後にタスクを追加するだけで、タスクは追加された順序（つまり、リソース割り当て関数が呼び出された順序）で実行されますか？

ありがとう、

RobertF

アプリケーション (Win64、C++) をより非同期にすることで改善しています。私はコンカレンシー ランタイムを使用していますが、これまでのところうまく機能しています。

アプリケーションは基本的に、データを変換する多数の「ジョブ」を実行します。各ジョブの動作を追跡するために、特定のサブシステムには、ジョブが実行する特定の操作を追跡するためのコードが組み込まれています。以前は、現在実行中のジョブを表す単一のグローバル変数を使用して、呼び出しチェーン全体でコンテキスト情報を渡すことなく追跡情報を登録できました。各ジョブは、ConcRT を使用してジョブ自体を並列化することもできます。これはすべて非常にうまく機能します。

ただし、トップレベルのジョブを並行して実行できるように、アプリケーションをリファクタリングしています。各ジョブは ConcRT タスクとして実行されます。これは、追跡が必要なジョブを除くすべてのジョブでうまく機能します。

私が基本的に必要としているのは、いくつかのコンテキスト情報をタスクに関連付け、そのタスクによって生成された他のタスクにそのフローを持たせる方法です。基本的に、「タスクローカル」変数が必要です。

ConcRT では、ジョブが ConcRT を使用して他のジョブを生成する可能性があり、これらは任意の数のスレッドで実行されるため、単純にスレッド ローカルを使用してコンテキスト情報を格納することはできません。

私の現在のアプローチでは、起動時に多数の Scheduler インスタンスを作成し、そのジョブ専用のスケジューラで各ジョブを生成します。次に、このConcurrency::CurrentScheduler::Id()関数を使用して、コンテキストを把握するためのキーとして使用できる整数 ID を取得できます。これは機能しますが、Concurrency::CurrentScheduler::Id()in アセンブリを 1 回ステップ実行すると、複数の仮想関数呼び出しと安全性チェックが実行され、かなりのオーバーヘッドが追加されるため、ややひるみます。場合によっては料金。

だから - これを達成するためのより良い方法はありますか? 単一のコンテキスト ポインターを現在の Scheduler/SchedulerGroup/Task に関連付けることができるファーストクラスの TaskLocal/userdata メカニズムがあれば、それをほとんどオーバーヘッドなく取得できればよかったのにと思います。

ConcRT スレッドが新しいタスクを取得するたびに呼び出されるフックが理想的です。これにより、Scheduler/ScheduleGroup ID を取得してスレッド ローカルに格納し、アクセス オーバーヘッドを最小限に抑えることができます。残念ながら、そのようなフックを登録する方法が見当たらず、PPL/エージェント用のカスタム スケジューラ クラスを実装することもできないようです (この記事を参照してください)。

これは、Microsoft C++ Concurrency API のコンテキストにあります。

agent（名前空間の下に）と呼ばれるクラスがありConcurrency、それは基本的に純粋な仮想を派生させて実装するステートマシンですagent::run。

ここで、実行可能なagent::start状態にするを呼び出すのはあなたの責任です。次に、* またはそのバリアントのいずれかを呼び出して、メソッドを実際に実行します。agent::waitagent::run

しかし、なぜagent::done体内で呼び出さなければならないのでしょうか? つまり、明らかな答えは、agent::wait* は完了が通知されるか、タイムアウトが経過するまで待機するということですが...

設計者は何を意図していたのですか？agent::run戻ったときにエージェントを完了状態に入れないのはなぜですか? それが私が知りたいことです。電話をかけないという選択肢があるのはなぜdoneですか? タイムアウトが経過すると、待機メソッドは例外をスローします。

私はtask_group、Visual Studio 2010 で単純なコンカレンシー ランタイムを使用して、作業を GUI スレッドから分離する単一の作業スレッドを実行しています。

しかし、私の同僚の 1 人は、私が CR を間違って使用していると言いました。これは、小さなコンテキストで軽量タスクを並列化するために設計されたものであり、かさばる I/O 依存スレッドを GUI から分離するためのものではありません。彼はこれをドキュメントから引用したと述べましたが、特定のリンクを提供することはできませんでした。

では、Microsoft Concurrency Runtime の制限と、使用してはいけない問題を解決するにはどうすればよいでしょうか?

もちろん、CR は移植性がありませんが、それは省略しましょう。コードをコンパイルしたときに問題が発生する状況について話しているのです。

C++ で非同期 HTTP GET を実装する必要があり、アプリを Windows 8 ストアに送信できる必要があります。

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

HttpRequest クラスを実装する適切なサンプル コードを見つけましたhttp://code.msdn.microsoft.com/windowsapps/HttpClient-sample-55700664

この例は、URI が正しい場合は機能しますが、URI が無効または存在しない場所 (www.google22.com など) を指している場合は例外をスローします。例外をキャッチできれば問題ありませんが、どこでどのようにキャッチすればよいかわかりません。

今いくつかのコード。これは、例外をスローする非同期の concurrency::task ベースのメソッドへの呼び出しです。

そして、これは GetAsync メソッドの関連セグメント (メソッドの最後) です。

CheckHResult 行は例外をスローします。これはコードです。

GetAsync 呼び出しの周りに try-catch があり、.then 継続ラムダにも try-catch があります。

関連する Microsoft のドキュメント ( http://msdn.microsoft.com/en-us/library/windows/apps/hh780559.aspx ) では、タスクによってスローされた例外は、チェーン内の次のタスクでキャッチ可能である必要があると述べていますが、どういうわけか私の場合はうまくいきません。さらに、呼び出し全体の try-catch でさえ例外をキャッチしません。すべてをすり抜けるだけです...

誰もこの問題を抱えていましたか？公式ドキュメントに記載されているすべてを試したと思いますが、それでも例外が暴走してアプリをクラッシュさせます。何が恋しいですか？

編集：

例外処理以外は何もしないようにコードを変更しましたが、.GetAsync のタスクによってスローされた例外をまだキャッチしません。

クリーンアップされたコード:

これでも、次の例外メッセージが表示されてクラッシュします。HRESULT:0x800C0005

さらに、コードにいくつかのブレークポイントを配置すると、最初の .then が呼び出される前に例外がすべてを通過することが示されます。これらの場所にブレークポイントを配置しました（簡略化/クリーンアップされたコード内）：

• GetAsync 呼び出しの前に
• GetAsync に、CheckHResult(std::get<0>(resultTuple)) に; 例外をスローする行
• すべての try and catch ケース / ブロックに

ブレークポイントでテストされた実行順序:

1. GetAsync 呼び出しの前 [OK]
2. GetAsync で、例外をスローする行 [OK]
3. 今、アプリがクラッシュし、すべての try-catch をすり抜けて、続行します
4. 最初の.thenの行が呼び出され、try ブロックで
5. どのキャッチ ブロックでもキャッチされない別のアプリ レベルの例外
6. 最初の.thenの catch ブロック
7. second .then メソッドのtryブロック
8. 2番目の.thenの catch は例外をキャッチしません

そして、出力されたデバッグ ログは次の順序で表示されます: - URI の取得を開始します... - App1.exe の 0x75644B32 での初回例外: Microsoft C++ 例外: Platform::COMException ^ メモリ位置 0x082FEEF0 で。HRESULT:0x800C0005 - App1.exe の 0x75644B32 での初回例外: Microsoft C++ 例外: [再スロー] メモリ位置 0x00000000 で。- App1.exe の 0x75644B32 での初回例外: Microsoft C++ 例外: Platform::COMException ^ メモリ位置 0x082FE670 で。HRESULT:0x800C0005 - App1.exe の 0x75644B32 での初回例外: Microsoft C++ 例外: Platform::COMException ^ メモリ位置 0x082FDD88 で。HRESULT:0x800C0005 - 不明な例外

何が起こっている？？

私は、他の職務の中でも、定期的に (1 時間に 1 回) サーバーに要求を行う C++ アプリケーションを作成しています。
このスケジュールされたタスクは中断され、早期に (アプリケーションが新しいユーザー データを受信したときに) 強制的に実行することができます。この目的のために ConcRT を使用することにしました。

• このようなスケジューリングの標準的な方法 (Win32 のタイマー キューなど) はありますが、タスクとタスク グループはありますか?
• または、タスクを継続してチェーンする必要がありますか?
• Agents Library の方が適しているのではないでしょうか? （私の問題ではやり過ぎだと思った）

PS HTTP 要求は古き良き WinHTTP で作成されます (実行可能ファイルはサードパーティのライブラリに依存せず、サイズを小さく保つ必要があります)。ConcRTメカニズムに準拠した、HTTPリクエスト機能の非同期実装はありますか?