Hi, I saw an event basically means setting a bit in a 32 bit integer, so, yes, they don't queue. I got into the same issue with rtems_message_queue_receive(RTEMS_NO_TIMEOUT), it blocks even if there are messages in the queue like I said. Not even rtems_message_queue_receive without timeout didn't return. But I don't think rtems_message_queue_receive/rtems_event_receive have bugs, I think these functions do their job, but if my task is not scheduled anymore, of course they don't make any progress.
I confirmed my task doesn't get CPU time by printing cpu_time_used from the TCB of the task. This is a cummulative value that signifies the total amount of CPU time the task got since its creation. After the issue is seen, I don't see this value incrementing at all, but other tasks get CPU slices. So my question is: why would a task stop getting CPU time ? Where is the code in the RTEMS scheduler that decides what is the next task to put on the CPU ? I saw there are 58 files with scheduler functionality in the code base .. where should I start to look ? regards, Catalin On Thu, Sep 20, 2018 at 5:05 PM Joel Sherrill <j...@rtems.org> wrote: > Also the subject says message queue and event receive but the scenario > described is just about events. Events do not queue. They are one deep. If > the receiving task ever misses an event send (2 sends before.one receive), > then the described scenario.is expected. > > --joel > > On Thu, Sep 20, 2018, 7:44 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello Catalin, >> >> could you please check if you have the same behaviour on the RTEMS master. >> >> On ARMv-7M and RTEMS exceptions and interrupts with a priority value of >> less than 0x80 are non-maskable with respect to the operating system and >> therefore must not use operating system services. If you use operating >> system services in non-maskable interrupts, then the system behaviour is >> quite undefined. >> >> -- >> 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 > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
