Movatterモバイル変換


[0]ホーム

URL:


cppreference.com
Namespaces
Variants
    Actions

      std::execution::sequenced_policy,std::execution::parallel_policy,std::execution::parallel_unsequenced_policy,std::execution::unsequenced_policy

      From cppreference.com
      <cpp‎ |algorithm
       
       
      Algorithm library
      Constrained algorithms and algorithms on ranges(C++20)
      Constrained algorithms, e.g.ranges::copy,ranges::sort, ...
      Execution policies(C++17)
      execution::sequenced_policyexecution::parallel_policyexecution::parallel_unsequenced_policyexecution::parallel_unsequenced
      (C++17)(C++17)(C++17)(C++20)
      Sorting and related operations
      Partitioning operations
      Sorting operations
      Binary search operations
      (on partitioned ranges)
      Set operations (on sorted ranges)
      Merge operations (on sorted ranges)
      Heap operations
      Minimum/maximum operations
      (C++11)
      (C++17)
      Lexicographical comparison operations
      Permutation operations
      C library
      Numeric operations
      Operations on uninitialized memory
       
      Defined in header<execution>
      class sequenced_policy{/* unspecified */};
      (1)(since C++17)
      class parallel_policy{/* unspecified */};
      (2)(since C++17)
      class parallel_unsequenced_policy{/* unspecified */};
      (3)(since C++17)
      class unsequenced_policy{/* unspecified */};
      (4)(since C++20)
      1) The execution policy type used as a unique type to disambiguate parallel algorithm overloading and require that a parallel algorithm's execution may not be parallelized. The invocations of element access functions in parallel algorithms invoked with this policy (usually specified asstd::execution::seq) are indeterminately sequenced in the calling thread.
      2) The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized. The invocations of element access functions in parallel algorithms invoked with this policy (usually specified asstd::execution::par) are permitted to execute in either the invoking thread or in a thread implicitly created by the library to support parallel algorithm execution. Any such invocations executing in the same thread are indeterminately sequenced with respect to each other. If the threads of execution created bystd::thread orstd::jthread provide concurrent forward progress guarantees, then the threads of execution created by the library provide parallel forward progress guarantees. Otherwise, the provided forward progress guarantee is implementation-defined. Note: parallel forward progress guarantees that if a thread of execution makes a step, it will eventually make another step, enabling threads to enter critical sections and take locks, because the thread that has the lock will be eventually scheduled again and be able to release it.
      3) The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized, vectorized, or migrated across threads (such as by a parent-stealing scheduler). The invocations of element access functions in parallel algorithms invoked with this policy are permitted to execute in an unordered fashion in unspecified threads, and unsequenced with respect to one another within each thread. The invocation of element access functions in parallel algorithms invoked with this policy are not permitted to invoke vectorization-unsafe operations, like those specified by the standard library to synchronize, including those ofstd::atomic and other concurrency primitives. If the threads of execution created bystd::thread orstd::jthread provide concurrent forward progress guarantees, then the threads of execution created by the library provide weakly parallel forward progress guarantees. Otherwise, the provided forward progress guarantee is that of the thread invoking the parallel algorithm. Note: weakly parallel forward progress guarantees that one of the threads of execution that have made a step will eventually make another step, which does not allow threads to enter critical sections or take locks, because the thread that has the lock may not be scheduled again until a thread that is attempting to take the lock has exited.
      4) The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be vectorized, e.g., executed on a single thread using instructions that operate on multiple data items.

      During the execution of a parallel algorithm with any of these execution policies, if the invocation of an element access function exits via an uncaught exception,std::terminate is called, but the implementations may define additional execution policies that handle exceptions differently.

      [edit]Notes

      When using parallel execution policy, it is the programmer's responsibility to avoid data races and deadlocks:

      int a[]={0,1};std::vector<int> v;std::for_each(std::execution::par,std::begin(a),std::end(a),[&](int i){    v.push_back(i*2+1);// Error: data race});
      std::atomic<int> x{0};int a[]={1,2};std::for_each(std::execution::par,std::begin(a),std::end(a),[&](int){    x.fetch_add(1,std::memory_order_relaxed);while(x.load(std::memory_order_relaxed)==1){}// Error: assumes execution order});
      int x=0;std::mutex m;int a[]={1,2};std::for_each(std::execution::par,std::begin(a),std::end(a),[&](int){std::lock_guard<std::mutex> guard(m);++x;// correct});

      Unsequenced execution policies are the only case where function calls areunsequenced with respect to each other, meaning they can be interleaved. In all other situations in C++, they areindeterminately-sequenced (cannot interleave). Because of that, users are not allowed to allocate or deallocate memory, acquire mutexes, use non-lockfreestd::atomic specializations, or, in general, perform anyvectorization-unsafe operations when using these policies (vectorization-unsafe functions are the ones that synchronize-with another function, e.g.std::mutex::unlock synchronizes-with the nextstd::mutex::lock).

      int x=0;std::mutex m;int a[]={1,2};std::for_each(std::execution::par_unseq,std::begin(a),std::end(a),[&](int){std::lock_guard<std::mutex> guard(m);// Error: lock_guard constructor calls m.lock()++x;});

      If the implementation cannot parallelize or vectorize (e.g. due to lack of resources), all standard execution policies can fall back to sequential execution.

      [edit]See also

      (C++17)(C++17)(C++17)(C++20)
      global execution policy objects
      (constant)[edit]
      Retrieved from "https://en.cppreference.com/mwiki/index.php?title=cpp/algorithm/execution_policy_tag_t&oldid=174658"

      [8]ページ先頭

      ©2009-2025 Movatter.jp