Why do threads start execution from _Thread_Handler?

[Richi Dubey]

Great explanation. This makes sense. Thank you, I will look further into
this.

Thanks
Richi.

On Sun, Jan 10, 2021 at 8:48 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>
> Gedare
>
>
>> 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/20210112/1fb8ee9f/attachment.html>