長時間実行可能なstd :: asyncは他のstd :: asyncを枯渇させることができますか？

Question

私が理解しているように、std :: asyncの通常の実装は、あらかじめ割り当てられたスレッドプールからのスレッドに対するこれらのジョブをスケジュールします。

だから、最初にスレッドプールを占有しているすべてのスレッドを占有するのに十分な長期実行型のメッセージを作成してスケジュールを設定しておきます（std::async）。その後すぐに（彼らの実行が終わるまで）、私は短時間実行してstd::asyncを作成してスケジュールします。長時間走っているものの少なくとも1つが終了するまで、短時間走っているものがまったく実行されないことが起こりうるか？あるいは、この種の状況を防ぐスタンダード（特にC++ 11）にいくつかの保証があります（OSがラウンドロビン方式でそれらをスケジューリングできるようにもっと多くのスレッドを生成するなど）？

Answer 1

標準読み取り：

打ち上げ::非同期がポリシーに設定されている場合[futures.async#3.1]、コールINVOKE(DECAY_­COPY(std​::​forward<F>(f)), DECAY_­COPY(std​::​forward<Args>(args))...)（[func.require]、[thread.thread.constr]）であたかも非同期を呼び出したスレッドで評価されるDECAY_COPYへの呼び出しを持つスレッドオブジェクトによって表される新しい実行スレッド。 [...] async()が​async起動ポリシーで呼び出されたとき

ので、として-IFのルールの下で、新しいスレッドが生み出されなければなりません。もちろん、インプリメンテーションはスレッドプールを内部的に使用することがありますが、通常のスレッド作成オーバヘッドは別として、特別な「飢え」は発生しません。さらに、スレッドローカルの初期化のようなものは常に起こるはずです。

実際には、打ち鳴らすのlibC++トランク非同期実装は読む：あなたが見ることができるよう

unique_ptr<__async_assoc_state<_Rp, _Fp>, __release_shared_count> 
     __h(new __async_assoc_state<_Rp, _Fp>(_VSTD::forward<_Fp>(__f))); 

VSTD::thread(&__async_assoc_state<_Rp, _Fp>::__execute, __h.get()).detach(); 

return future<_Rp>(__h.get()); 

、NO '明示的な' スレッド・プールは、内部的に使用されていません。

さらに、hereを読むことができるので、gcc 5.4.0で出荷されるlibstdC++の実装では、単なるスレッドが呼び出されます。

Answer 2

はい、MSVCのstd::asyncは、少なくともMSVC2015以降はそのプロパティを持つようです。

2017年のアップデートで修正したかどうかわかりません。

これは標準の精神に反します。しかし、この規格はスレッドの進捗状況の保証については非常に曖昧です（少なくともC++ 14では）。したがって、std::asyncはstd::threadをラップするように動作する必要がありますが、std::threadフォワード進行の保証は十分に弱いため、as-ifルールでの保証はあまりありません。実際に

、これはその問題を持っているように見えていませんMSVC2015でstd::threadの生の使用など、std::threadに生のコールと私のスレッドプールの実装でstd::asyncを置き換えるために私をリードしてきました。

は、私が（タスクキュー付き）スレッドプールがstd::asyncまたはstd::threadのいずれかに生のコールよりもはるかに実用的であることがわかり、それがstd::threadまたはstd::asyncのいずれかでスレッドプールを書くことは本当に簡単ですと、私がお勧めしますstd::threadと書いてください。

スレッドプールは、std::asyncのように返すことができます（ただし、プール自体がスレッドの存続期間を管理するため、破壊機能の自動ブロッキングはありません）。

私は、C++ 17がより進歩的な進歩保証を追加したと読んだが、MSVCの動作が現在の標準要件に反していると結論づけるのに十分な理解がない。