Why do threads start execution from _Thread_Handler?

Gedare Bloom gedare at rtems.org
Sun Jan 10 15:18:11 UTC 2021

Hi Richi,

On Mon, Jan 4, 2021 at 10:53 AM Richi Dubey <richidubey at gmail.com> wrote:

> Hi,
> I am debugging a code (tm24
> <https://git.rtems.org/rtems/tree/testsuites/tmtests/tm24/task1.c>) and
> there is a scenario where a thread is blocked on the CPU and a new thread
> has to start executing in its place. So, the thread which is getting
> blocked (executing thread) executes the _Thread_Do_dispatch and runs the
> code until
> <https://git.rtems.org/rtems/tree/cpukit/score/src/threaddispatch.c#n308>:
> _Context_Switch( &executing->Registers, &heir->Registers ). After this,
> the heir thread starts executing from _Thread_Handler. Why is this the
> case? Should the heir not start its execution from where the (earlier)
> executing thread left the program counter at, i.e. after the
> _Context_Switch in _Thread_Do_dispatch?
I think Sebastian answered this for you before? The heir thread will resume
execution wherever its PC value is pointing to, which does not need to be
the same place that the executing task is departing. In RTEMS however the
cases are fairly limited, with the PC of a task that never executed before
pointing into _Thread_Handler, because you have to start somewhere. For
tasks that have been executing before and have been preempted/yielded, they
will go through the _Thread_Do_dispatch code and their stored PC will
indeed resume them at that point you mention.


> Please let me know your thoughts.
> Thanks,
> Richi.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210110/ab2ca305/attachment.html>

More information about the devel mailing list