問題タブ [stdasync]

私はstd::async、将来のコンパイラの実装でそれをどのように使用すべきかについて考えてきました。ただし、現在、設計上の欠陥のように感じられるものに少し行き詰まっています。

はstd::asyncかなり実装に依存しており、おそらく 2 つのバリアントがlaunch::asyncあります。1 つはタスクを新しいスレッドに起動し、もう 1 つはスレッド プール/タスク スケジューラを使用します。

ただし、これらのバリアントのどれを実装するためstd::asyncに使用するかによって、使用方法は大きく異なります。

「スレッドプール」ベースのバリアントの場合、オーバーヘッドをあまり気にせずに多くの小さなタスクを起動できますが、ある時点でタスクの 1 つがブロックされたらどうなるでしょうか?

一方、「新しいスレッドを起動する」バリアントは、タスクをブロックしても問題は発生しませんが、タスクの起動と実行のオーバーヘッドは非常に高くなります。

thread-pool: +low-overhead, -決してブロックしない

新しいスレッドを立ち上げます: +ブロックで細かい、-高いオーバーヘッド

したがって、基本的には実装に応じて、使用方法はstd::async非常に慎重になります。あるコンパイラで問題なく動作するプログラムがある場合、別のコンパイラではひどく動作する可能性があります。

これは設計によるものですか？または、何か不足していますか？私と同じように、これを大きな問題と考えますか?

現在の仕様ではstd::oversubscribe(bool)、実装に依存しないstd::async.

編集: 私が読んだ限りでは、C++ 11 標準ドキュメントには、送信されたタスクstd::asyncがブロックされるかどうかに関するヒントはありません。

Herb Sutter のプレゼンテーションからこのコードを実行します。これは、gcc 4.6.3 の Linux では問題なく動作します。future.h は mingw ではサポートされていないと思いますが、エラーが非常にわかりにくいです。

エラーは次のとおりです。

WindowsでGCC 4.7を使用しています。

C++ And Beyond からのこのクリップの冒頭近くで、std::async. 2 つの質問があります。

1. ジュニア開発者向けに、 を使用する際に何をすべきか、何を避けるべきかについての一連のルールはありstd::asyncますか?

2. このビデオで紹介されている問題は何ですか? それらはこの記事に関連していますか?

私は DCPU-16 エミュレーターを作成しており、別のスレッドで関数 getRealTimeCPUClock() を呼び出すスレッドを起動して、CPU のリアルタイム クロック速度を計算しています。問題は、値が返されていない場合でも、future オブジェクトの「valid」属性が true であるように見えることです。その結果、futureObj.get() を呼び出すと、getRealTimeCPUClock() が戻るまで待機します。

非同期の起動ポリシー (遅延ではなく) では、関数をバックグラウンドで起動し、返されたときに有効な属性を true に設定することは想定されていませんか?

これは間違った使い方ですか？

すでにジョブの抽象化レイヤーを作成するためのWorkerクラスとクラスがあります。Handlerミックスに非同期性を注ぎ込むために使用したかったstd::asyncのですが、Visual Studio 2012（アップデート1）から奇妙な動作が発生しました。

私のクラス階層は次のとおりです。

• Workerは、純粋仮想メソッドを使用する抽象クラスInitですWork。
• BasicWorker : Worker単にprintfいくつかの出力に使用しています。
• GroupWorker : Worker他の労働者の集合体です。
• HandlerWorkerいくつかの仕事をするために保持します。

次にstd::async、ワーカーとハンドラーを作成するいくつかのメソッドを呼び出し、ネストされた呼び出しでハンドラーを呼び出し、ワーカーのstd::async初期化（ここ）を待ってstd::condition_variableからハンドラーを停止します。

最後に、すべてのが終了するのを待ちstd::futureます。

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

私の問題は：

• 関数内の行のコメントを解除するとWaitForInit@GroupWorker、ネストされた非同期関数呼び出しは、すべての第1レベルの非同期関数呼び出しが行われるまで行われません。
• ジョブの数を増やすのを待っstd::condition_variableている間、新しいスレッドの作成は指数関数的に遅くなるように感じます。100未満のジョブのトライアルでは、非同期が存在しますが、300を超えると、ジョブを作成するのは完全にシーケンシャルです。
• 次にprintf、メソッドの行のコメントを解除するStartと、ネストされたすべての非同期が魅力のように機能します

それで、

• 使用法で何が間違っていますstd::condition_variableか？
• 何百ものスレッドのように、ジョブの作成が遅くなるのはなぜですか？（この質問はオプションであり、OSの問題のようであり、スマートスレッドプールの概念で修正できます）
• これとは何printfの関係がありますか？（競合状態の場合にすべての呼び出しを削除しようとprintfしましたが、コードにブレークポイントを設定しましたが、ヘルプはありません。これも同じですstd::cout）

編集：スレッドの作成を保証するための起動ポリシー（Jonathan Wakelyによって提案された）を追加しました。しかし、それも役に立ちませんでした。私は現在、第1レベルの非同期内で待機するための関数std::threadと呼び出し関数を作成しています。thread::join

別のスレッドで実行するラムダに完全に転送したい関数テンプレートがあります。以下は、直接コンパイルできる最小限のテスト ケースです。

コンパイルしていない場合のエラー メッセージの最後の行は次のとおりです。

の推定方法に関係があるのではないかと感じていますT&&が、正確な障害点を特定して修正することはできません。助言がありますか？

ありがとうございました！

編集：これがコンパイラの問題である可能性がある場合に備えて、gcc 4.7.0を使用しています（おそらくそうではありません）

以下のコードは、.then（）タイプの継続の実装に関するHerbSutterのアイデアに基づいています。

これはauto next = then(f, [](int r) { go_and_use(r); });、同様に使用されます。

これは素晴らしいアイデアですが、現状では機能しません（将来は移動のみでコピー可能ではありません）。私が推測できる限り、c ++の今後のバージョンに表示される可能性が高いため、このアイデアは気に入っています（ただし、.then（）または待機している場合もあります）。

先物を共有または類似させる前に、スタックオーバーフローコミュニティは、特に改善と提案（共有された先物でさえ）でこの実装をどのように考えるでしょうか？

提案を事前に感謝します。

（これは、スレッドのコストがかかるため、標準ベースのメカニズムが存在するまでの修正であることを認識しています（多分）））。

私が正しければ、std :: asyncは新しいスレッドを使用し、その中のメソッドを呼び出します。メインスレッドまたは親スレッドが停止するとどうなるのだろうかと思っていました。asyncメソッドを制御しているスレッドも停止しますか？

std :: asyncメソッドにタイムアウトを実装する方法はありますか？そのため、スレッドが指定された時間完了しなかった場合に、この呼び出しをタイムアウトして完了させたいと思います。この機能を実装するにはどうすればよいですか。

重複の可能性：
C ++ 11でフューチャーをキャンセル/デタッチする方法はありますか？

とを使用して非同期で実行されるメンバー関数がありstd::futureますstd::async。場合によってはキャンセルする必要があります。（関数はオブジェクトの近くを連続してロードし、ロード中にオブジェクトが範囲外になることがあります。）同じ問題に対処するこの質問の回答をすでに読んでいますが、機能させることができません。

これは、私の実際のプログラムと同じ構造の単純化されたコードです。非同期の実行中に呼び出しStart()を行うとKill()、のアクセス違反が原因でクラッシュが発生しますinput。

私の目には、コードは次のように機能するはずです。がKill()呼び出されると、実行フラグは無効になります。次のコマンドget()は、スレッドが終了するのを待つ必要があります。これは、実行中のフラグをチェックするため、すぐに終了します。スレッドがキャンセルされた後、inputポインタは削除されます。

スレッドは実行中のフラグをfalseに切り替えることに気付いていないようです。私の間違いは何ですか？