C++標準化委員会の文書 2015-05 post-Lenexaのレビュー: N4501-N5409

N4501: Technical Specification for C++ Extensions for Concurrency, Working Draft

同期まわりの標準ライブラリに対する拡張TS、futureの改良、latch/barrierライブラリ、アトミックスマートポインター。

[PDF注意] N4502: Proposing Standard Library Support for the C++ Detection Idiom, V2

void_tを使ったdetection idiomのためのライブラリを追加する提案の改訂版

前回のN4436と比べて、具体的な文面案が追加されているようだ。

[PDF注意] N4505: Working Draft, Technical Specification for C++ Extensions for Parallelism

並列版アルゴリズムライブラリであるParallelism TSのドラフト。既存のアルゴリズムと同じインターフェースにポリシーを指定すると並列実行してくれる。

[PDF注意] N4506: Parallelism TS Editor's Report

Parallelism TSの編集者による変更点の記述。

[PDF注意] N4507: Technical Specification for C++ Extensions for Parallelism

Parallelism TSの文面。内容なN4505と同じ。

N4508: A proposal to add shared_mutex (untimed) (Revision 4)

C++11のshared_mutexは、C++14でshared_timed_mutexに改名された。C++11のshared_mutexは、実際にはtimed lock要件を満たす必要があるためである。さて、開いたshared_mutexに、timed lockではなく、素のLockable要件のみを満たすものを追加しようという提案。

N4509: constexpr atomic<T>::is_always_lock_free

atomicの実装は、クリティカルセクションのようなロックを必要とする実装であっても、規格準拠である。これは、ロックフリーのアトミック操作を直接提供していないアーキテクチャ上でもatomicを実装可能であり、移植性の向上につながる。

しかし、プログラマーは実装がロックフリーかどうかを知って、それによって実装を切り替えたがるものだ。規格はその需要を満たすために、bool atomic<T>::is_lock_freeメンバー関数を提供している。また、ATOMIC_..._LOCK_FREEマクロもある。

問題は、実装が常にロックフリーかどうかは、コンパイル時にわからないこともある。そこで、マクロの値は、0,1,2のいずれかを取り、それぞれ、ロックフリーではない、条件付きでロックフリー、常にロックフリーという意味を持つ。

このため、常にロックフリーであることを示す、SFINAEで使いやすいconstexperメンバー関数、constexpr bool atomic<T>::is_always_lock_freeを追加しよう