Effective Modern C++ ―C++11/14プログラムを進化させる42項目

280

｜

7 章 並行 API

上例を用いれば、検知タスクのコードは容易に記述できます。

… // detect event

イベントを検知

p.set_value(); // tell reacting task

反応タスクへ通知

反応タスクのコードもやはり単純です。

… // prepare to react

反応処理の準備

p.get_future().wait(); // wait on future

// corresponding to p

p に対応する future でウェイト

… // react to event

イベント反応処理

この mutex を用いない設計も、先に挙げたフラグを用いた方式同様に、反応タスクが wait する

より先に検知タスクが std::promise をセットしても問題なく動作しますし、疑似ウェイクアップ

も問題になりません（影響を受けるのは条件変数のみ）。また、条件変数を用いた方式同様に、反応

タスクは wait を呼び出せば真のブロック状態になるため、ウェイト中にシステムリソースを消費

しません。完璧じゃないですか？

いえ、そうでもありません。future を用いれば確かに多くの問題を回避できます。しかし、検討

すべき問題点はまだあります。例えば項目 38 で述べたように、std::promise と future の間には

共有ステートが存在し、共有ステートは一般にダイナミックに割り当てられます。そのため、この

設計にはヒープの割り当て／解放というコストがかかることを忘れてはなりません。 ...