3

As I understand it, usual implementations of std::async schedule these jobs on threads from a pre-allocated thread pool.

So lets say I first create and schedule enough long-running std::asyncs to keep all threads from that thread pool occupied. Directly afterwards (before long they finished executing) I also create and schedule some short-running std::asyncs. Could it happen that the short-running ones aren't executed at all until at least one of the long-running ones has finished? Or is there some guarantee in the standard (specifically C++11) that prevents this kind of situation (like spawning more threads so that the OS can schedule them in a round-robin fasion)?

4

2 に答える 2

0

はい、std::async少なくともMSVC2015の時点では、MSVCにはまさにそのプロパティがあるようです。

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

これは、標準の精神に反します。ただし、標準は、スレッドの前方進行の保証について非常にあいまいです (少なくとも C++14 の時点では)。したがって、は a をstd::asyncラップするかのように動作する必要がありますが、前方への進行std::threadの保証std::threadは十分に弱いため、as-if ルールの下ではあまり保証されません。

実際には、これによりstd::async、スレッドプールの実装を への生の呼び出しに置き換えるようになりました。MSVC2015std::threadでの の生の使用にstd::threadはその問題がないようです。

std::asyncスレッド プール (タスク キューを使用) は、またはの生の呼び出しよりもはるかに実用的であることがわかりました。また、またはstd::threadを使用してスレッド プールを作成するのは非常に簡単であるため、 を使用してスレッド プールを作成することをお勧めします。std::threadstd::asyncstd::thread

std::futureスレッド プールはs と同じように返すことができますstd::async(ただし、プール自体がスレッドの有効期間を管理するため、破棄機能の自動ブロックはありません)。

C++17 がより良い進行保証を追加したことを読みましたが、MSVC の動作が現在標準要件に反しているかどうかを結論付けるのに十分な理解がありません。

于 2017-11-30T15:36:37.713 に答える