作者:
IKAFIRE (沒有)
2016-05-17 02:23:41因為推文感覺問題描述不清楚，乾脆回一篇問問題
看完這三個policy之後對於他的設計感到有點疑惑，因此跑回去看draft
這是今年二月的版本
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r1.html
前一篇已經把這個草稿的精髓描述過了
我在這邊只節錄草稿中對於每個policy效果的描述
##sequential_execution_policy
The invocations of element access functions in parallel algorithms invoked
with an execution policy object of type sequential_execution_policy are
indeterminately sequenced (in) the calling thread.
基本上似乎是個fallback用的policy，讓你在不改變呼叫形式的情況下也可以避免平行化
只是有個疑問，為什麼要設計成「不保證執行順序 (indeterminately sequenced)」呢？
有趣的是在2015的初稿中，原本是保證依序執行的，不知甚麼原因被改掉了
##parallel_execution_policy
The invocations of element access functions in parallel algorithms invoked
with an execution policy object of type parallel_execution_policy are
permitted to execute in an unordered fashion in either the invoking thread or
in a thread implicitly created by the library to support parallel algorithm
execution.
還蠻好想像的行為，沒甚麼問題
##parallel_vector_execution_policy
The invocations of element access functions in parallel algorithms invoked
with an execution policy of type parallel_vector_execution_policy are
permitted to execute in an unordered fashion in unspecified threads, and
unsequenced with respect to one another within each thread.
問題來了，這個policy的優點何在？
乍看之下與parallel_execution_policy相較沒有額外的好處，還會引入很多問題
例如前篇也提過的，許多synchronization都可能會變成deadlock
甚麼樣的情況下會不用上一個policy而採用這個？