I'm currently trying to confirm my understanding of what precisely
happens during a switch-back of a shadow thread from primary to
secondary mode. I guess the thrilling things happen in xnshadow_relax().
The shadow enters in primary and leaves in secondary.

The question for me is now if I got these details right: first a
migration request is issued [1] but not immediately executed, then the
priority of the root thread (Linux) is lifted to the one of the shadow
thread [2], and then the shadow thread is suspend with respect to the
xenomai scheduler [3]. The last step should let the Linux kernel start
over again, run to its next preemption point (and this is the region
where non-deterministic delays may be injected with current kernels,
isn't it?), and switch over to lostage_handler() [4] to resume the Linux
part of the shadow thread. After that the execution of the shadow, now
in secondary mode, continues in xnshadow_relax() after [3]. Am I right?


[1] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L540
[2] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L542
[3] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L543
[4] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L254

Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to