問題タブ [stdthread]

重複の可能性:
C++ 2011 : std::thread : ループを並列化する簡単な例?

ベクトルの要素に計算を分散する次のプログラムを考えてみましょう (以前は std::thread を使用したことがありません)。

コードにはすでに 2 つの質問が埋め込まれています。

3 つ目は、次のようなものです: このコードはまったく問題ありませんか、それとも std::threads を使用してより洗練された方法で記述できますか? std::thread を使用した「グッドプラクティス」がわかりません...

私はstd::threadを初めて使用し、をコーディングしようとしますparallel_for。私は次のことをコーディングしました：

しかし、これは機能していません:( g ++ 4.6からのエラーコード）

この問題を解決する方法は？

編集：この新しいバージョンはコンパイルされますが、良い結果は得られません：

結果は次のとおりです。

パラレルバージョンは4950を返しますが、シーケンシャルバージョンは155を返します.....問題はどこにありますか？

重複の可能性:
std::thread を使用するための類似点?

を実装する次のコードを検討してくださいparallel_for。

ideone ( http://ideone.com/GrYJsQ ) では次のようになります:

一方、g++ 4.6 を搭載した私のコンピューターでは、 (g++ -O3 -std=c++0x parallel_for.cpp -o parallel_for -lpthreadおよび./parallel_for)が得られます。

問題はどこだ ？

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

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

Visual Studio 2012 を使用して新しい std::thread を使用する方法を理解しようとしています。次のコードをコンパイルしようとしています。

警告 C4930 という警告が表示されます: 'scoped_thread t(std::thread (__cdecl *)(local_functor))': プロトタイプ化された関数が呼び出されませんでした (意図した変数定義でしたか?)

はい、意図した変数定義でした。どうすればいいですか？

スレッドを使用してスパンする必要がある関数のオーバーロードを持つことは可能ですか?

Complex という単純なクラスがあります。

このコードをビルドするとエラーが発生します。

符号なしを取るオーバーロードされた表示関数がない場合、私が示したコードは正常に動作します。

std::thread使用する適切なクラスを決定するのに役立ついくつかのヒューリスティックを確立しようとしています。

私が理解しているように、最高レベル（最も使いやすいが、柔軟性が最も低い）から最低レベルまで、次のものがあります。

1. std::async with/std::future (std::shared_future) (1 回限りのスロー アウェイ プロデューサー スレッド非同期で実行する場合)
2. std::packaged_task (プロデューサーを割り当てたいが、スレッドへの呼び出しを延期する場合)
3. std::promise (???)

最初の 2 つをいつ使用するかについては十分に把握していると思いますが、についてはまだ不明ですstd::promise。

std::future呼び出しと組み合わせてstd::async、作成中のコールバック/ファンクター/ラムダを非同期呼び出しに効果的に変換します (定義により、すぐに戻ります)。単一のコンシューマーはstd::future::get()、ブロッキング呼び出しである を呼び出して、その結果を取得できます。

std::shared_futureは、複数のコンシューマを許可する単なるバージョンです。

std::future値をプロデューサ コールバックにバインドしたいが、実際の呼び出しを後で (タスクをスポーン スレッドに関連付けるとき) 延期したい場合は、std::packaged_taskが正しい選択です。しかし、一般的なケースでは、 に対応std::futureする はstd::package_task複数のスレッドからアクセスされる可能性があるため、std::mutex. std::asyncを使用すると、最初のケースでは、ロックについて心配する必要がないことに注意してください。

promise に関するいくつかの興味深いリンクを読んだので、そのメカニズムとその設定方法は理解できたと思いますが、私の質問は、他の 3 つよりも promise を使用することを選択するのはいつですか?

リンクの答えとは対照的に、経験則（上記の3.で???を埋める）のようなアプリケーションレベルの答えをもっと探しています（たとえば、 std::promise を使用していくつかのライブラリを実装します）メカニズム)、したがって、適切なクラスを選択する方法を の初心者ユーザーに簡単に説明できますstd::thread。

言い換えれば、他のメカニズムではstd::promiseできなくて、私が でできることの有用な例があればいいのにと思います。

答え

Astd::futureは奇妙な獣です。一般に、その値を直接変更することはできません。

その値を変更できる 3 つのプロデューサーは次のとおりです。

1. std::asyncstd::futureインスタンスを返す非同期コールバックを介して。
2. std::packaged_taskスレッドに渡されると、そのコールバックが呼び出され、それにstd::future関連付けられたインスタンスが更新されますstd::packaged_task。このメカニズムにより、プロデューサの早期バインディングが可能になりますが、後で呼び出すことができます。
3. std::promise、これにより、その呼び出しstd::futureを通じて関連付けられたものを変更できます。set_value()このように a の変更を直接制御することでstd::future、複数のプロデューサーが存在する場合に設計がスレッドセーフであることを確認する必要があります (std::mutex必要に応じて使用します)。

SethCarnegieの答えだと思います：

これを考える簡単な方法は、値を返すか、Promise を使用して未来を設定できるということです。future には設定方法がありません。その機能は約束によって提供されます。

promise をいつ使用するかを明確にするのに役立ちます。ただしstd::mutex、使用法によっては異なるスレッドから promise にアクセスできる可能性があるため、 a が必要になる場合があることに注意する必要があります。

また、デビッドのロドリゲスの答えも優れています。

通信チャネルのコンシューマー側は std::future を使用して共有状態からデータを消費し、プロデューサー スレッドは std::promise を使用して共有状態に書き込みます。

しかし、別の方法として、単純std::mutexに結果の stl コンテナーで a を使用し、プロデューサーの 1 つのスレッドまたはスレッドプールをコンテナーで動作させないのはなぜでしょうか? std::promise結果の stl コンテナーと比べて読みやすさが向上する以外に、代わりに を使用すると何が得られるのでしょうか?

コントロールはstd::promiseバージョンの方が優れているようです:

1. wait() は、結果が生成されるまで、特定の未来をブロックします
2. プロデューサー スレッドが 1 つしかない場合、ミューテックスは必要ありません。

次の google-test は、helgrind と drd の両方に合格し、単一のプロデューサーで、wait() を使用すると、ミューテックスが不要であることを確認します。

テスト

std::threadaが実行を終了したかどうかを確認したいと思います。stackoverflow を検索すると、この問題に対処する次の質問が見つかりました。受け入れられた答えは、終了する直前にワーカースレッドに変数を設定させ、メインスレッドにこの変数をチェックさせることを提案しています。このようなソリューションの最小限の実例を次に示します。

受け入れられた回答についてコメントした人は、単純なbool変数をシグナルとして使用することはできず、コードはメモリバリアなしで壊れており、使用std::atomic<bool>は正しいと主張しています。私の最初の推測では、これは間違っていて単純boolで十分ですが、何かが欠けていないことを確認したいと思います。上記のコードstd::atomic<bool>を正しくするには、 が必要ですか?

メインスレッドとワーカーが異なるソケットの異なる CPU で実行されていると仮定しましょう。私が思うに、メイン スレッドthread_finishedは CPU のキャッシュから読み取ります。ワーカーがそれを更新すると、キャッシュ コヒーレンシ プロトコルがワーカーの変更をグローバル メモリに書き込み、メイン スレッドの CPU のキャッシュを無効にする処理を行うため、グローバル メモリから更新された値を読み取る必要があります。上記のようなコードを機能させるには、キャッシュの一貫性が重要なのではないでしょうか?