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