因為推文感覺問題描述不清楚，乾脆回一篇問問題 看完這三個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而採用這個？ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.176.119.253 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1463423025.A.33A.html