Doubt regarding thread creation in RTEMS

[Richi Dubey]

Hi,

_Thread_Clear_state_locked( the_thread, STATES_ALL_SET );

I did have a look at it, it unblocks the node belonging to the_thread, I'll
go through everything again.

When you use the debugger to figure out what is going on I would step in
> to each function you don't know.

Got it. Thank you.


On Mon, Jul 20, 2020 at 9:24 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 20/07/2020 17:16, Richi Dubey wrote:
>
> > Hi,
> >
> > I am trying to map out how a task gets scheduled according to a
> > scheduling algorithm once a user writes rtems_task_create() and later
> > rtems_task_start() in the source file.
> >
> > On debugging with gdb, I came to realize that the
> >
> > rtems_task_start() function calls _Thread_Start()
> > (cpukit/rtems/src/taskstart.c : 56) then _Thread_Start() calls
> > _Thread_Dispatch_enable() ( cpukit/score/src/threadstart.c : 50 ) then
> > _Thread_Dispatch_enable() calls _Thread_Do_dispatch( )
> > (cpukit/score/src/threaddispatch.c : 377)
> > and _Thread_Do_dispatch calls _Thread_Get_heir_and_make_it_executing()
> > (threaddispatch.c : 282).
> >
> > _Thread_Get_heir_and_make_it_executing( cpu_self ) forcefully executes
> > the heir thread on the cpu_self.
> > (cpukit/include/rtems/score/threadimpl.h : 1117)
> >
> > If I am right, this flow of code makes the thread created by
> > rtems_task_create(..., id) execute on a CPU when rtems_task_start(...,
> > id) is called.  Shouldn't this decision of executing a thread on any
> > CPU be in the hands of the scheduler?  I'd be grateful if someone
> > could provide their views on this.
>
> Yes, the scheduler decides which of the ready threads gets a scheduler
> assigned. In _Thread_Start() please have a look at:
>
> _Thread_Clear_state_locked( the_thread, STATES_ALL_SET );
>
> >
> > Also, what is thread_dispatch_disable_level?
>
> This is a per-CPU variable. If thread_dispatch_disable_level != 0, then
> thread changes are prohibited on this processor. If it changes from 1 to
> 0, then it is checked if a thread dispatch is necessary.
>
> > Please know that I skipped reading some if conditions and some code
> > related to ISRs and other things that weren't directly related to
> > scheduling.
> When you use the debugger to figure out what is going on I would step in
> to each function you don't know.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200721/259a4fa1/attachment.html>