Hi, I see _Scheduler_priority_Ready_queue_enqueue calls _Chain_Append_unprotected which has an interesting comment * @note It does NOT disable interrupts to ensure the atomicity of the * append operation.
Catalin On Mon, Oct 22, 2018 at 4:08 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 22/10/2018 15:00, Catalin Demergian wrote: > > I started to look in the ready queues implementation. I added a debug > > patch tracing my tasks having priority=100. > > The way I see it, a task can enter a ready queue only > > > with > _Scheduler_priority_Ready_queue_enqueue/_Scheduler_priority_Ready_queue_enqueue_first > > and can be removed only by _Scheduler_priority_Ready_queue_extract. > > Yes. > > > I logged what rtems_clock_get_ticks_since_boot returns for every task > > and what I found was that for SCrx task this value is way behind the > > value for > > other tasks, meaning after a point is not added in the ready queue > > anymore. > > I tried with debugger too, following the next pointers to see what's > > in the ready_queue[100] and my task is not there, even if I see the > > state is ready > > when doing task command in shell. > > any idea what might be causing this? > > The thread state is Thread_Control::current_state, the code sequences to > block/unblock a thread should take care that ready threads > (current_state == 0) are visible to the scheduler (enqueued). Something > might have gone wrong during a non-ready to ready thread state transition. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
