What is the expected thread execution in tm24?

[Joel Sherrill]

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/20210114/84625ffc/attachment.html>