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 <j...@rtems.org> wrote: > > > On Thu, Jan 14, 2021 at 12:30 AM Richi Dubey <richidu...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
