Doubt regarding thread creation in RTEMS

[Richi Dubey]

Hi,

Could you please explain what _User_extensions_Thread_start does? It's hard
to understand it all by myself since it has a lot of other information
related to objects.

The brief for it says:
/**
 * @brief Starts a thread.
 *
 * @param created The thread to start.
 */

This is exactly what my doubt was. When we unlocked the node by setting the
state to ready by calling _Thread_Clear_state_locked, shouldn't the node be
scheduled if the scheduler sees it fit? Why are we enabling thread dispatch
on the current cpu (Shouldn't it depend on the affinity of the thread)?

Please tell me what happens in principle after
calling _Thread_Clear_state_locked().

Thank you.

On Tue, Jul 21, 2020 at 11:42 AM Richi Dubey <richidubey at gmail.com> wrote:

> 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/d0248591/attachment.html>