Re: [PATCH 3/4 v0.4] sched/umcg: add Documentation/userspace-api/umcg.rst

[Thierry Delisle]

> This is a wake, not a context switch, right?

I followed the "worker to worker context switch" procedure in the
documentation.

> I'm not sure why you are concerned with context switching here. And even
> if it were a context switch, the kernel manages thread stacks properly,
> there's nothing to worry about.

The reason I'm interested in this particular operation is because the
outcome is decided by an invisible race (between W1 and W2) in the
kernel. W2 might context-switch to W1 and it might not. Note I don't mean
race in the problematic sense, just that there are two possible outcomes
that are decided by relative speed. I'm wondering how many outcomes the
users needs to program for and if they may have to back-track anything.

For example, if W2 wants to "yield to", it must enqueue itself in the
user scheduler before the system call. But if the system call doesn't
context-switch and W2 keeps running, it may need to undo the enqueue.

I agree the comment about the stack was a tangent and I expected the
kernel to handle it. But, I believe, how the kernel handles this case
affects the number of outcomes for this scenario.

> If both cmpxchg() succeeded, but W1 was never put to sleep, ttwu()
> will do nothing and W1 will continue running on its initial CPU, while
> W2 will continue running on its own CPU. WF_CURRENT_CPU is an advisory
> flag, and in this situation it will not do anything.

This does not sound right to me. If ttwu does nothing, W1 and W2 keep
running. Who sets W2's state back to RUNNING?

Is W2 responsible for doing that? It's not "the party initiating
the state transition" in this case.

Since there is no way for W2 to tell if it did context-switch to W1, does
that mean that W2 should always cmpxchg() its state to RUNNING after a
sys_umcg_wait()?