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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
