What is the expected thread execution in tm24?

Richi Dubey richidubey at gmail.com
Sun Jan 17 16:37:11 UTC 2021


Hi,

Sorry for my late reply, I missed this email in my inbox for some reason.

Thank you for your quick reply.

every REST thread having a unique priority.

a unique priority which is the same for all the OPERATION_COUNT REST
threads, right?

Rest(pri=2)
>    - rtems_task_exit
> .... more Rest threads
> Rest(pri=lowest based on operation count)
>     there is an if which checks that operation_count says to stop)
>     end timer

Please explain this. How do we get a REST task with priority=2? Do all the
REST tasks not have a priority of (RTEMS_MAXIMUM_PRIORITY / 2u) + 1u, =
approx 512/2 + 1 = 257? I know that what you are saying is correct because
when I debug the code while one of the REST thread is executing, I can see
that there are two threads with priority 2 in the blocked state.


As I write this, I find it strange that you have issues with this test and
> not one of the sptests which should be setting up the same situation.

Yes, the following tasks fail: I tried debugging sp02 sp16 but they were
complex and hard to debug. tm24 seemed like the easiest to solve :p.

 sp02.exe
 sp16.exe
 sp30.exe
 sp31.exe
 sp37.exe
 sp42.exe
 spfatal29.exe
 tm24.exe

On Thu, Jan 14, 2021 at 7:10 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Jan 14, 2021 at 12:30 AM Richi Dubey <richidubey at gmail.com> wrote:
>
>> Hi,
>>
>> In the Tasks function
>> <https://git.rtems.org/rtems/tree/testsuites/tmtests/tm24/task1.c#n106>,
>> when one of the OPERATION_COUNT thread calls rtems_task_wake_after(
>> RTEMS_YIELD_PROCESSOR), it yields the processor and goes
>> <https://docs.rtems.org/releases/rtemsdocs-4.6.2/share/rtems/html/c_user/c_user00077.html>
>> in the ready state. So, is it expected that the same thread gets the
>> execution again after the call to rtems_task_wake_after(
>> RTEMS_YIELD_PROCESSOR)? - because it is one of the threads with the
>> highest priority and is in the ready queue - like call to
>> <https://git.rtems.org/rtems/tree/testsuites/tmtests/tm24/task1.c#n90>
>> rtems_task_wake_after in the High_task function?
>>
>
> I think you have missed this piece of code in the test:
>
> status = rtems_task_create(
>       rtems_build_name( 'R', 'E', 'S', 'T' ),
>       (RTEMS_MAXIMUM_PRIORITY / 2u) + 1u,
>
>  Init and High_Task have priority 1 and all the REST have lower priorities
> with every REST thread having a unique priority.
>
> The test should execute
>
> Init
> High
>   - benchmark yield which returns to the same thread
>   - start time
>   - rtems_task_exit
> Rest(pri=2)
>    - rtems_task_exit
> .... more Rest threads
> Rest(pri=lowest based on operation count)
>     there is an if which checks that operation_count says to stop)
>     end timer
>
>>
>> If yes, the thread finishes its execution after the call to
>> rtems_task_wake_after and the function also ends, does RTEMS try to find
>> the next heir to execute?
>>
>
> rtems_task_wake_after(yield) in High should return. There are no other
> threads at priority 1 and the REST should have no impact. They are all
> lower priority.
>
> The other yield cases are when the caller is not preemptible and that is
> keeping higher priority threads from running. And when there are multiple
> threads at the same priority.
>
> Both of those are more complicated than this where there is nothing else
> at this priority.
>
> As I write this, I find it strange that you have issues with this test and
> not one of the sptests which should be setting up the same situation.
>
> --joel
>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210117/8e0410fa/attachment.html>


More information about the devel mailing list