Make internal algorithms functions const

[msimberg]

HPX parallel algorithms wrap element-wise functions into bigger functions that operate on chunks. These functions are non-const. In the Kokkos executors I invoke those wrapping functions inside a Kokkos parallel region, and Kokkos expects element-wise functions to be const. This is a workaround that marks HPX functions like operator() for for_loop_iteration as const, and its members as mutable. As far as I can tell we can't make them properly const because of requirements in HPX itself, but I may be wrong here. Also as far as I can tell we don't really violate anything fundamental in Kokkos by doing this. Kokkos mostly requires functions to be const to discourage modifying e.g. members in a parallel region since that can be difficult to get right. Of course, this does feel very wrong, so I'm opening this up to see if someone would have suggestions on how to avoid this.

Note: I've only done this for for_loop, for_each, and transform as those are the only parallel algorithms that currently work with the Kokkos executors. Others will need specialization instead of going through our parallel algorithm machinery.

[hkaiser]

I would like to try and not make the members mutable (if you haven't tried that) to see what actually breaks. I think the main reason for not making those const in the first place was that the user supplied function objects might be mutable themselves.

[msimberg]

I would like to try and not make the members mutable (if you haven't tried that) to see what actually breaks. I think the main reason for not making those const in the first place was that the user supplied function objects might be mutable themselves.

Yep, I'll have a closer look at what exactly needs to be non-const. The user-supplied functions will be a problem in the end though. I'd imagine we don't actually want to require them to be const?

[hkaiser]

The user-supplied functions will be a problem in the end though. I'd imagine we don't actually want to require them to be const?

Those are specifically allowed to be non-const, think of a function object that counts odd numbers using a for_each for instance...

[msimberg]

The user-supplied functions will be a problem in the end though. I'd imagine we don't actually want to require them to be const?

Those are specifically allowed to be non-const, think of a function object that counts odd numbers using a for_each for instance...

Yep, that's that I thought.

[msimberg]

@hkaiser here's a log of building transform_test as an example: https://gist.github.com/msimberg/172506305a9a3df6aa777cef34800ab3. This is with the current revision on this branch (i.e. 21ee2dd). Making the operator()s here:

hpx/libs/algorithms/tests/unit/algorithms/transform_tests.hpp

Lines 21 to 37 in a98d61f

	struct add_one
	{
	template <typename T>
	T operator()(T const& v)
	{
	return v + 1;
	}
	};
	struct throw_always
	{
	template <typename T>
	T operator()(T)
	{
	throw std::runtime_error("test");
	}
	};

const makes at least that particular test compile. Given that the user supplied are allowed to be non-const there are a few options of which only the two last ones seem reasonable:

• add some mutable
• I've missed some other place in the algorithms that should be changed that would make this compile
• specialize algorithms for the Kokkos executors (where we would require user-supplied functions to be const)
  Given our discussions outside of here, the last one seems like the best option in the end. It'll anyway be required for most algorithms.

@G-071 this branch is what you need right now as a workaround to have the Kokkos executors work with parallel algorithms.

[hkaiser]

@msimberg let's specialize the algorithms for Kokkos, I think this will result in the cleanest solution.