発表資料です

1. Effec%ve
Modern
C++
Item
35:
Prefer
task-­‐based
programming
to
thread-­‐based.
@keisukefukuda

2. doAsyncWork()という関数を非同期実行したい
ü Thread-­‐based
ü Task-­‐based
int
doAsyncWork();
std::thread
t
(doAsyncWork);
int
doAsyncWork();
auto
fut
=
std::async(doAsyncWork);
std::future<T>

3. std::asyncの利点
一般的に、task-­‐basedな方法の方が優れている
1. doAsyncWork()の戻り値の取得（get()関数）
2. doAsyncWork()が例外を送出する場合
• threadだとstd::terminate()が呼ばれてプロセス死亡
• std::asyncではget()が同じ例外を再送出する
3. より抽象化されている

4. 抽象化されるべきthread-­‐basedモデルの詳細
(1)
threadという用語
ConcurrentなC++において、threadという用語は
3つの意味を持ちうる
1. Hardware
thread
実際に計算を実行するスレッド
最近のマシンは、CPU
coreごとに複数のスレッド
をサポートする
=
Intel
x86
CPUでいうとHyperThreading

5. 抽象化されるべきthread-­‐basedモデルの詳細
(1)
threadという用語
ConcurrentなC++において、threadという用語は
3つの意味を持ちうる
2. SoTware
thread
• OSによって、プロセッサ全体で管理されるスレッド（い
わゆる普通の意味でのスレッド）
• HW
threadに割り付けられて実行される
• HW
threadよりも多く作られることができる。IO遅延や
条件変数等によるアイドル時間を削減してスループッ
トを向上させる

6. 抽象化されるべきthread-­‐basedモデルの詳細
(1)
threadという用語
ConcurrentなC++において、threadという用語は
3つの意味を持ちうる
3. std::thread
• SW
threadへのハンドラを保持する、C++でのオブジェ
クト。1つのSW
threadのハンドルを持つか、nullであ
る
– 関数無しのデフォルトコンストラクタで初期化された場合
– std::moveでmoveされた
– joinもしくはdetachされた

7. 抽象化されるべきthread-­‐basedモデルの詳細
(2)
SW
threadは有限資源
システムが提供できるSW
threadの数には制限があるので、不
足の場合は std::system_errorが送出される
int
doAsyncWork()
noexcept;
だとしても、
std::thread
t(doAsyncWork);
が例外を送出する可能性が常にある

8. 抽象化されるべきthread-­‐basedモデルの詳細
(2)
SW
threadは有限資源
SW
threadが足りないときどうするか？（threadで頑張るなら）
• 同じスレッド内で（逐次に）実行する
ü スレッド間で負荷の不均衡が生じる可能性
ü 当該のスレッドがGUIスレッドだとレスポンスに問題
• 実行中のどれかのSW
threadが終わるのを待つ
ü もし選ばれたthreadが doAsyncWork()の結果等に依存
していたらデッドロック

9. 抽象化されるべきthread-­‐basedモデルの詳細
(2)
SW
threadは有限資源
SW
threadが足りるとしても、oversubscrip%on問題が
（HW
threadに対して
SW
threadが多すぎる）
ü OSのスケジューラは、%me
sliceで複数のSW
threadをHW
threadに割り付ける
ü スレッド切り替え（コンテキストスイッチ）はスレッド管理の
コストを増加させる
ü あるSW
threadが別コアに行ってしまうと、CPUキャッシュ
がcold
startになる
ü 同じコアでも、別スレッドに切り替わった後に戻ってくると、
キャッシュが汚染されている

10. hYps://wiki.csiro.au/display/ASC/Understanding+the+CPU+Cache

11. 抽象化されるべきthread-­‐basedモデルの詳細
(2)
SW
threadは有限資源
oversubscrip%onが問題だと行っても、HW
threadとSW
threadの
適正な比率は不明：
ü IO律速か、計算律速か
ü コンテキストスイッチのコスト（CPUとOSによる）
ü SW
threadがキャッシュをどれくらい有効に使っているか
→
諸々の詳細、アーキテクチャ、マシンスペック、実装に依存
要するにわからん

12. これらの問題を，アプリの実装で解決しようとするのではなく
て、他の誰かに押しつけよう！
「他の誰か」
=
C++
standard
libraryの実装者
ü std::async（asyncとは言ってない）
によってSW
threadが実際に作られるかどうかは保証されてい
ない
→ SW
threadの資源量の問題は何とかしてくれるんじゃない
の？
ü 負荷の不均衡問題は解決できるとは限らないけど、プログラマ
よりランタイムライブラリ・スケジューラの方が情報を多く持って
る
ü GUIスレッドの件は解決できないが、Item36
で扱う
std::launch::async
を使えば強制できる

13. 最新のスケジューラーは、thread
poolとwork
stealingによってoversubscrip%onと負荷の不均衡
の問題を改善している
（例：Intel
TBB）
Thread
pooling:
あらかじめ一定個のスレッドを常駐させておいて、タスク
をどれかのスレッドに割り当てる方式
hYps://en.wikipedia.org/wiki/Thread_pool_paYern

14. 最新のスケジューラーは、thread
poolとwork
stealingによってoversubscrip%onと負荷の不均衡
の問題を改善している
（例：Intel
TBB）
Work
stealing：
タスクからタスクが生成されるようなアプリケーションにおいて、
スレッドプールのスレッドごとにキューを持ち、自分のキューが
空になったら他のスレッドのキューからタスクを取ってくる

15. 最新のスケジューラーは、thread
poolとwork
stealingによってoversubscrip%onと負荷の不均衡
の問題を改善している
（例：Intel
TBB）
実は、C++規格の一部が、thread
pool
のような実
装を採用することを難しくしている
(thread_local
とか？）
とはいえ、これからも技術の進展が期待できるの
で、std::async
を使って書いておけば、自動的
にその恩恵が受けられる！

16. threadを直接扱う方が良い場合：
• 下位レイヤのスレッド実装のAPIを呼び出す
必要がある場合
• threadの利用方法を、アプリケーションないで
最適にできる
&&
したい場合
• C++実装が、利用したいプラットフォーム上で
thread
pool等をサポートしておらず自分で書
く必要がある場合

17. Things
to
remember
• std::thread
は、非同期実行された関数の戻り値を取得す
る方法を提供せず、また例外が送出されればプログラム
が終了してしまう
• Thread-­‐based
プログラミングでは、SW
thread資源の枯渇、
oversubscrip%on、負荷の不均衡の問題に対して手動で対
策を取る必要がある
• Task-­‐basedプログラミングでデフォルトのlaunch
policyを使
えば、それらの問題の大半は自動的になんとかしてくれる