ExecutionSpace: flattened OpState

[maartenarnst]

Food for thought :) An alternative design with an opstate.

The main change is that in this design, work is launched from the start function on host. This way, we avoid launching it from the set_value function that the standard seems to want to run on the execution agent, which may be the device.

If we make the op state queryable for the exec, we can decide in the start functor whether or not to fence.

[romintomasetti]

This has no chance to work.

Say we have:

auto chain = stdexec::schedule(esc.get_scheduler()) | stdexec::then(..A..) | stdexec::then(..B..);
stdexec::sync_wait(std::move(chain));

What you'll get is:

1. the operation state of sync_wait will start the operation state of B
2. operation state of B calls operation state of A
3. operation state of A call operation state of the scheduler, that call the set value on its receiver
4. thus calling set value on A recevier
5. calling set value on B receiver
6. calling set value on sync_wait receiver
7. triggering the sync wait fence
8. Only after that does control return to A operation state start() function, which then launches kernel A.
9. Then control returns to B operation state start() function, which launches kernel B

So you got everything in the wrong order, well done 👍

I agree we can have operation states, yet, it's the call to the ThenReceiver set_value that tells us "now is the time to launch you async operation".

And so we're back to the same situation that #262 solves.

If you feel strongly about this, you can followup on #262 and move all the propagate_completion_signal stuff in some operation state, much like in nvexec.

[maartenarnst]

I agree it can't work on its own. We'd have to modify the schedule sender and sync wait too. Essentially, the start function of the op state of the schedule sender would do nothing. The one of the sync wait would fence.

The issue that this tries to solve is that we currently launch work and fence in our set_value functions. And if we read the standard literally, it seems to say that the set_value must run on an execution agent, i.e. the gpu. This is a problem because we can't launch and fence from device. So even if we don't retain the upstate from this PR, there's the food for thought 😄.

[romintomasetti]

We'd have to modify the schedule sender and sync wait too.

It will not help you with the when_all case at all.

[maartenarnst]

Hey @romintomasetti. This is more concretely what I am thinking of. There are two commits:

• the first step introduces a ThenOpstate
• the second step moves the launch from the set_value function to the start function of this op state (there is still work here, the ordering is currently not right)

The main reason I think of the second step is point 10 from https://eel.is/c++draft/exec#async.ops-10:

[A scheduler] is a factory for senders whose asynchronous operations execute value completion operations on an execution agent belonging to the scheduler's associated execution resource.

I interpret this as saying that the set_value will in principle be called on device. And so that's why I feel it may not be the best place to launch work.

There could also be a third step and move the launch into a "child opstate". There could be some nice links with graph nodes in that case.

[romintomasetti]

LEt's also update the PR description.

[romintomasetti]

I think this is not right.

You'd better have a helper that givens you the ParallelForSender type given the Data and Sndr.

[romintomasetti]

Let's not write it at all, it does not serve any purpose (error channel or overload resolution) and just make it harder to read.

[romintomasetti]

Seems useless ?