You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Fotis Panagiotopoulos <f....@gmail.com> on 2022/07/21 15:27:28 UTC
Simulator loop task.
Hello,
I am having some issues with scheduling in simulator.
I noticed that there is a "loop task", that performs various house-keeping
tasks.
This task is started with a priority of SCHED_PRIORITY_MIN.
Is this correct / on-purpose?
I would expect this task to run on maximum priority, simulating various
interrupt or timer events that an MCU would normally have.
Re: Simulator loop task.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
Hello,
SIM_WALLTIME_SIGNAL indeed seems the correct option for me, exactly what I
need.
Unfortunately, it is not working.
The function sim_timer_update() is correctly called on the first signal
that the host delivers.
Then the simulation crashes during the execution of the function
oneshot_callback() in the file nuttx/drivers/timers/arch_alarm.c.
I will investigate further...
On Fri, Jul 22, 2022 at 3:29 PM Xiang Xiao <xi...@gmail.com>
wrote:
> On Fri, Jul 22, 2022 at 6:58 PM Fotis Panagiotopoulos <f.j.panag@gmail.com
> >
> wrote:
>
> > The loop task indeed needs to run in high priority. I provided a PR for
> > this.
> >
> > However, the functionality in up_idle cannot be transferred to the loop
> > function. This is because:
> > * Either the loop task will execute, and no one will be able to preempt
> it.
> > * Or the loop task will get to sleep, but will never wake-up because it
> > itself advances the system timer.
> >
> > The system timer needs another way to run in simulator, better emulating
> > the interrupt-based behaviour of an actual target.
> >
> > Any ideas?
> >
> >
> Yes, it's a chicken-and-egg problem, that's why we still keep the timer
> related stuff in the idle thread.
> The solution is:
>
> 1. Enable the tickless mode, so the caller can get the changing
> timestamp even if it is in a busy loop. All busy loops we encounter
> before
> can be fixed by this method.
> 2. Move the timer related stuff to the host signal handler by
> enabling SIM_WALLTIME_SIGNAL(
>
> https://github.com/apache/incubator-nuttx/blob/master/arch/sim/Kconfig#L132-L139
> ),
>
> But since SIM_WALLTIME_SIGNAL is seldom used, you may hit some stability
> issues.
>
>
> >
> > On Thu, Jul 21, 2022 at 10:14 PM Xiang Xiao <xi...@gmail.com>
> > wrote:
> >
> > > On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos <
> > > f.j.panag@gmail.com>
> > > wrote:
> > >
> > > > Here is the actual issue:
> > > >
> > > > The timer g_system_timer is updated in the IDLE task.
> > > > This causes problems, because time is not advancing if the system
> does
> > > not
> > > > have any idle time.
> > > >
> > > >
> > > Ok, you don't enable tickless mode. If you enable it like us, the
> > > timestamp will reflect the real value even if some thread is busy.
> > >
> > > The timer behaves erratically, or just gets stuck.
> > > > For example, a spin-lock-like structure, as is the following snippet,
> > > works
> > > > correctly on a hardware target, but locks-up in sim:
> > > >
> > > > while ((clock() - start) < TIMEOUT)
> > > > {
> > > > if (foo())
> > > > break;
> > > > }
> > > >
> > > > I thought that I should move g_system_timer in the loop task, but
> then
> > I
> > > > realized that it also runs at SCHED_PRIORITY_MIN.
> > > >
> > > > I expect similar problems on other parts of the simulator, in such
> > > > spin-lock like codes.
> > > > For example while waiting for serial input, without any sleep.
> > > > (Practically all cases that are normally served by interrupts).
> > > >
> > > >
> > > > My proposition is to:
> > > > * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works
> and I
> > > > don't expect side effects).
> > > > * Move the remaining logic within the idle task to the loop task.
> > > >
> > > >
> > > > What do you think?
> > > >
> > > >
> > > I think it's fine or better to use the highest priority thread to
> > simulate
> > > the interrupt.
> > >
> > >
> > > >
> > > > On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <
> xiaoxiang781216@gmail.com>
> > > > wrote:
> > > >
> > > > > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > > > > f.j.panag@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am having some issues with scheduling in simulator.
> > > > > > I noticed that there is a "loop task", that performs various
> > > > > house-keeping
> > > > > > tasks.
> > > > > >
> > > > > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > > > > Is this correct / on-purpose?
> > > > > >
> > > > > >
> > > > > The house keeping work ran in the idle loop before, but since some
> > work
> > > > may
> > > > > sleep/wait internally, we have to move them to the "loop task".
> > That's
> > > > why
> > > > > we select SCHED_PRIORITY_MIN.
> > > > >
> > > > >
> > > > > > I would expect this task to run on maximum priority, simulating
> > > various
> > > > > > interrupt or timer events that an MCU would normally have.
> > > > > >
> > > > >
> > > > > It should be fine to increase the priority of the "loop task".
> > > > >
> > > >
> > >
> >
>
Re: Simulator loop task.
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Jul 22, 2022 at 6:58 PM Fotis Panagiotopoulos <f....@gmail.com>
wrote:
> The loop task indeed needs to run in high priority. I provided a PR for
> this.
>
> However, the functionality in up_idle cannot be transferred to the loop
> function. This is because:
> * Either the loop task will execute, and no one will be able to preempt it.
> * Or the loop task will get to sleep, but will never wake-up because it
> itself advances the system timer.
>
> The system timer needs another way to run in simulator, better emulating
> the interrupt-based behaviour of an actual target.
>
> Any ideas?
>
>
Yes, it's a chicken-and-egg problem, that's why we still keep the timer
related stuff in the idle thread.
The solution is:
1. Enable the tickless mode, so the caller can get the changing
timestamp even if it is in a busy loop. All busy loops we encounter before
can be fixed by this method.
2. Move the timer related stuff to the host signal handler by
enabling SIM_WALLTIME_SIGNAL(
https://github.com/apache/incubator-nuttx/blob/master/arch/sim/Kconfig#L132-L139
),
But since SIM_WALLTIME_SIGNAL is seldom used, you may hit some stability
issues.
>
> On Thu, Jul 21, 2022 at 10:14 PM Xiang Xiao <xi...@gmail.com>
> wrote:
>
> > On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos <
> > f.j.panag@gmail.com>
> > wrote:
> >
> > > Here is the actual issue:
> > >
> > > The timer g_system_timer is updated in the IDLE task.
> > > This causes problems, because time is not advancing if the system does
> > not
> > > have any idle time.
> > >
> > >
> > Ok, you don't enable tickless mode. If you enable it like us, the
> > timestamp will reflect the real value even if some thread is busy.
> >
> > The timer behaves erratically, or just gets stuck.
> > > For example, a spin-lock-like structure, as is the following snippet,
> > works
> > > correctly on a hardware target, but locks-up in sim:
> > >
> > > while ((clock() - start) < TIMEOUT)
> > > {
> > > if (foo())
> > > break;
> > > }
> > >
> > > I thought that I should move g_system_timer in the loop task, but then
> I
> > > realized that it also runs at SCHED_PRIORITY_MIN.
> > >
> > > I expect similar problems on other parts of the simulator, in such
> > > spin-lock like codes.
> > > For example while waiting for serial input, without any sleep.
> > > (Practically all cases that are normally served by interrupts).
> > >
> > >
> > > My proposition is to:
> > > * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
> > > don't expect side effects).
> > > * Move the remaining logic within the idle task to the loop task.
> > >
> > >
> > > What do you think?
> > >
> > >
> > I think it's fine or better to use the highest priority thread to
> simulate
> > the interrupt.
> >
> >
> > >
> > > On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <xi...@gmail.com>
> > > wrote:
> > >
> > > > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > > > f.j.panag@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I am having some issues with scheduling in simulator.
> > > > > I noticed that there is a "loop task", that performs various
> > > > house-keeping
> > > > > tasks.
> > > > >
> > > > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > > > Is this correct / on-purpose?
> > > > >
> > > > >
> > > > The house keeping work ran in the idle loop before, but since some
> work
> > > may
> > > > sleep/wait internally, we have to move them to the "loop task".
> That's
> > > why
> > > > we select SCHED_PRIORITY_MIN.
> > > >
> > > >
> > > > > I would expect this task to run on maximum priority, simulating
> > various
> > > > > interrupt or timer events that an MCU would normally have.
> > > > >
> > > >
> > > > It should be fine to increase the priority of the "loop task".
> > > >
> > >
> >
>
Re: Simulator loop task.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
The loop task indeed needs to run in high priority. I provided a PR for
this.
However, the functionality in up_idle cannot be transferred to the loop
function. This is because:
* Either the loop task will execute, and no one will be able to preempt it.
* Or the loop task will get to sleep, but will never wake-up because it
itself advances the system timer.
The system timer needs another way to run in simulator, better emulating
the interrupt-based behaviour of an actual target.
Any ideas?
On Thu, Jul 21, 2022 at 10:14 PM Xiang Xiao <xi...@gmail.com>
wrote:
> On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos <
> f.j.panag@gmail.com>
> wrote:
>
> > Here is the actual issue:
> >
> > The timer g_system_timer is updated in the IDLE task.
> > This causes problems, because time is not advancing if the system does
> not
> > have any idle time.
> >
> >
> Ok, you don't enable tickless mode. If you enable it like us, the
> timestamp will reflect the real value even if some thread is busy.
>
> The timer behaves erratically, or just gets stuck.
> > For example, a spin-lock-like structure, as is the following snippet,
> works
> > correctly on a hardware target, but locks-up in sim:
> >
> > while ((clock() - start) < TIMEOUT)
> > {
> > if (foo())
> > break;
> > }
> >
> > I thought that I should move g_system_timer in the loop task, but then I
> > realized that it also runs at SCHED_PRIORITY_MIN.
> >
> > I expect similar problems on other parts of the simulator, in such
> > spin-lock like codes.
> > For example while waiting for serial input, without any sleep.
> > (Practically all cases that are normally served by interrupts).
> >
> >
> > My proposition is to:
> > * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
> > don't expect side effects).
> > * Move the remaining logic within the idle task to the loop task.
> >
> >
> > What do you think?
> >
> >
> I think it's fine or better to use the highest priority thread to simulate
> the interrupt.
>
>
> >
> > On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <xi...@gmail.com>
> > wrote:
> >
> > > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > > f.j.panag@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I am having some issues with scheduling in simulator.
> > > > I noticed that there is a "loop task", that performs various
> > > house-keeping
> > > > tasks.
> > > >
> > > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > > Is this correct / on-purpose?
> > > >
> > > >
> > > The house keeping work ran in the idle loop before, but since some work
> > may
> > > sleep/wait internally, we have to move them to the "loop task". That's
> > why
> > > we select SCHED_PRIORITY_MIN.
> > >
> > >
> > > > I would expect this task to run on maximum priority, simulating
> various
> > > > interrupt or timer events that an MCU would normally have.
> > > >
> > >
> > > It should be fine to increase the priority of the "loop task".
> > >
> >
>
Re: Simulator loop task.
Posted by Xiang Xiao <xi...@gmail.com>.
On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos <f....@gmail.com>
wrote:
> Here is the actual issue:
>
> The timer g_system_timer is updated in the IDLE task.
> This causes problems, because time is not advancing if the system does not
> have any idle time.
>
>
Ok, you don't enable tickless mode. If you enable it like us, the
timestamp will reflect the real value even if some thread is busy.
The timer behaves erratically, or just gets stuck.
> For example, a spin-lock-like structure, as is the following snippet, works
> correctly on a hardware target, but locks-up in sim:
>
> while ((clock() - start) < TIMEOUT)
> {
> if (foo())
> break;
> }
>
> I thought that I should move g_system_timer in the loop task, but then I
> realized that it also runs at SCHED_PRIORITY_MIN.
>
> I expect similar problems on other parts of the simulator, in such
> spin-lock like codes.
> For example while waiting for serial input, without any sleep.
> (Practically all cases that are normally served by interrupts).
>
>
> My proposition is to:
> * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
> don't expect side effects).
> * Move the remaining logic within the idle task to the loop task.
>
>
> What do you think?
>
>
I think it's fine or better to use the highest priority thread to simulate
the interrupt.
>
> On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <xi...@gmail.com>
> wrote:
>
> > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > f.j.panag@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I am having some issues with scheduling in simulator.
> > > I noticed that there is a "loop task", that performs various
> > house-keeping
> > > tasks.
> > >
> > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > Is this correct / on-purpose?
> > >
> > >
> > The house keeping work ran in the idle loop before, but since some work
> may
> > sleep/wait internally, we have to move them to the "loop task". That's
> why
> > we select SCHED_PRIORITY_MIN.
> >
> >
> > > I would expect this task to run on maximum priority, simulating various
> > > interrupt or timer events that an MCU would normally have.
> > >
> >
> > It should be fine to increase the priority of the "loop task".
> >
>
Re: Simulator loop task.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
Here is the actual issue:
The timer g_system_timer is updated in the IDLE task.
This causes problems, because time is not advancing if the system does not
have any idle time.
The timer behaves erratically, or just gets stuck.
For example, a spin-lock-like structure, as is the following snippet, works
correctly on a hardware target, but locks-up in sim:
while ((clock() - start) < TIMEOUT)
{
if (foo())
break;
}
I thought that I should move g_system_timer in the loop task, but then I
realized that it also runs at SCHED_PRIORITY_MIN.
I expect similar problems on other parts of the simulator, in such
spin-lock like codes.
For example while waiting for serial input, without any sleep.
(Practically all cases that are normally served by interrupts).
My proposition is to:
* Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
don't expect side effects).
* Move the remaining logic within the idle task to the loop task.
What do you think?
On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <xi...@gmail.com>
wrote:
> On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> f.j.panag@gmail.com>
> wrote:
>
> > Hello,
> >
> > I am having some issues with scheduling in simulator.
> > I noticed that there is a "loop task", that performs various
> house-keeping
> > tasks.
> >
> > This task is started with a priority of SCHED_PRIORITY_MIN.
> > Is this correct / on-purpose?
> >
> >
> The house keeping work ran in the idle loop before, but since some work may
> sleep/wait internally, we have to move them to the "loop task". That's why
> we select SCHED_PRIORITY_MIN.
>
>
> > I would expect this task to run on maximum priority, simulating various
> > interrupt or timer events that an MCU would normally have.
> >
>
> It should be fine to increase the priority of the "loop task".
>
Re: Simulator loop task.
Posted by Xiang Xiao <xi...@gmail.com>.
On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <f....@gmail.com>
wrote:
> Hello,
>
> I am having some issues with scheduling in simulator.
> I noticed that there is a "loop task", that performs various house-keeping
> tasks.
>
> This task is started with a priority of SCHED_PRIORITY_MIN.
> Is this correct / on-purpose?
>
>
The house keeping work ran in the idle loop before, but since some work may
sleep/wait internally, we have to move them to the "loop task". That's why
we select SCHED_PRIORITY_MIN.
> I would expect this task to run on maximum priority, simulating various
> interrupt or timer events that an MCU would normally have.
>
It should be fine to increase the priority of the "loop task".