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 <ged...@rtems.org> wrote: > Hi Richi, > > On Mon, Jan 4, 2021 at 10:53 AM Richi Dubey <richidu...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
