bulk doesn't give the caller a way to constrain how function can be executed

[lewissbaker]

There is currently no way for a caller that invokes the bulk() algorithm to indicate to that algorithm that a given strategy for invoking f is either allowed or not allowed to invoke f concurrently.

Ideally, the caller of bulk() would be able to pass an execution policy (e.g. seq, par, unseq, par_unseq) to indicate in which ways it is safe to execute f.

e.g. stdex::bulk(pred, stdex::par, n, f) to indicate that f is safe to call concurrently on multiple threads from an execution context that provides parallel forward progress, but not safe to call concurrently from execution agents with weak forward progress guarantees.

e.g. stdex::bulk(pred, stdex::seq, n, f) to indicate that f is only safe to call sequentially, even if you're on an execution context that can potentially execute across multiple threads.

[lucteo]

I don't have a strong opinion on this (partially because I'm not that deep into the execution policy subject), but it feels to me that this is not something that we need to support.

I don't think that stdex::bulk(pred, stdex::seq, n, f) makes too much sense. The user is better of using then() with a for loop. Then, maybe we are better off without customizing for execution policy.

This would also require everyone who customizes bulk (which, in my mind, bulk is made to be customized) to write multiple customizations. Do we think that customizing for unseq and par_unseq is worth the trouble?

If we don't allow this specification now, I think we can always add it later. So, maybe it makes sense to consider this when we have good experience with cases in which we need this (we may have those already, and I just don't know; sorry about that).

[LeeHowes]

Do we think that customizing for unseq and par_unseq is worth the trouble?

par and unseq would certainly be worth the trouble in many cases. What I don't like about bulk as specified is that we are still in a position of having execution policies mean two things. We seem to have drifted over time to have them be prescriptive about how something should execute. The earlier discussions were much more about permission to run the callable in a certain way. I would like to stick to the permissive definition, and have the prescription on the scheduler tie in to that.

[lewissbaker]

The earlier discussions were much more about permission to run the callable in a certain way. I would like to stick to the permissive definition, and have the prescription on the scheduler tie in to that.

Yes, I think at least @LeeHowes, @rarutyun and myself are in agreement that the execution policy should be passed by callers to grant permission to execute the function in certain ways, but not be prescriptive about how it must be run. And the plan is to put that into a paper suggesting improvements to bulk (and also to apply the same pattern to other parallel algorithms).

[inbal2l]

Issue will be addressed in: "P3481: Summarizing std::execution::bulk() issues" (Lewis Baker, Lucian Radu Teodorescu, Ruslan Arutyunyan)