On 2021/09/09 10:41, Yasushi SHOJI wrote:
On Thu, Sep 9, 2021 at 12:01 AM Katsuhiro Suzuki
On 2021/09/08 16:22, Yasushi SHOJI wrote:The reason why we set _current to the new thread is that we can't set it after
On Wed, Sep 8, 2021 at 10:23 AM Katsuhiro Suzuki <katsuhiro@...> wrote:Because to keep consistency for another context switching (by preemption) and
Why do you `use _current_cpu` at all? `_arch_switch()` or
`arch_switch()` on the main branch takes
both new and old thread handles.
Only _current_cpu.current is available when an interrupt occurred.
we switch to the new thread. The newly switched thread will just start
the point it left off. Otherwise, we have to make sure that each and
every arch must
set _current to the new thread in `arch_switch()`.
Hmm... It seems that in CONFIG_USE_SWITCH=n case (ex. aarch32(*)) _current_cpu.current
is updated by software interrupt handler.
So I wonder that why CONFIG_USE_SWITCH=y changed strategy to update current thread.
At an IRQ, you know the `_current` is the currently executing thread and you can
get a new thread from ready_q, if needed.
At explicit switch, you are given both old and new threads.
So in both cases, we _can_ implement the switch.
Right and agree with you. If this is intentional behavior and we encourage
CONFIG_USE_SWITCH=y case to separate from old code, I want to follow it.
I don't have any claim to current context switching specification, just want to
know "why changed?".
I agree that we need to do similar things for arch_switch and irq, and
love to use
exact same code for both, but it might be better to have separate code for
each situation. Or, at least use .macro to construct parts of it.
ps. Unfortunately, unlike the Linux kernel, we don't have any way to
get the thread struct
from a stack pointer, IIRC.
Yeah, this is Zephyr. Not Linux :)
just my 2 cents,