@ericniebler and @chriskohlhoff
When I am trying to compile this library inside the VxWorks environment.
<execution> header in this library conflicts with the system <execution>.

is it a standard requirement to have in this library?

like to know your thoughts on this, any workaround also appreciated.

Consider adding in the Readme which proposal number this code is tracking (and maybe which revision it is currently implementing).

It looks like the implementation still uses the pre-R7 form of properties like blocking, bulk_guarantee, etc. There's a fair amount of complexity in the new form of properties, and it's probably worth coding them up sooner rather than later.

Hi

we are looking into putting together a std::executors backend for Kokkos https://github.com/kokkos/kokkos/tree/std-executors-backend
and I am puzzling over how to best implement a parallel_reduce (or in stl terms a transform_reduce).

One straight forward way seems to be to use the bulk_twoway_execute and use the ResultFactory to provide a handle to a std::atomic. While that probably would work no matter what the executor type is (as long as it supports bulk_twoway_execute) it is also an exceptionally slow way of implementing a reduction.

// Insert this into the for_each example
template<class ExecutionPolicy, class RandomAccessIterator, class T, class Function>
T transform_reduce(ExecutionPolicy&& policy, RandomAccessIterator first, RandomAccessIterator last, T init, std::plus<> , Function f)
{
  auto n = last - first;

  std::atomic<T> result = init;
  auto twoway_bulk_exec = execution::require(policy.executor(), execution::bulk, execution::twoway);

  twoway_bulk_exec.bulk_twoway_execute([=](size_t idx,  std::atomic<T>* result, impl::ignored&)
  {
    T val = init;
    *result += f(first[idx]);
  },
  n,
  [&]()-> std::atomic<T>* {return &result;},
  []{ return impl::ignore; }
  ).get();
  return result;
}

void foo() {
  std::vector<int> vec(10);
  for(int i=0; i<10; i++) vec[i] = i;
  int result = transform_reduce(par,vec.begin(),vec.end(),0,std::plus<>(),[&] (int& ptr) -> int {
    return ptr;
  });
  assert(result == 45);
}

Now if I know that the executor is mapping to std::thread I could probably do something with a map to get from the thread id to a scratch space location in the range of 0 to concurrency, so that I can store each threads contribution and then do some serial reduction later (or the last thread done does its stuff or something like that). But that requires the knowledge of executor mapping to std::thread. Is there something I am overlooking? Is the possibility of implementing this in a general way just outside of what executors are supposed to address for now?