rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

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.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181022/26972860/attachment-0002.html>