RTEMS | broadcasting message to single task with higher importance priority can generate multiple messages (#4804)

[MITHILESH MATTAPALLI (@mithileshm)]

MITHILESH MATTAPALLI commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4804#note_142819


I am looking into this issue as part of my **GSoC 2026** proposal.

I've reviewed the current implementation of `_CORE_message_queue_Broadcast` and wanted to validate the root cause. The infinite loop appears to be a classic preemption race: when `_Thread_queue_Extract` unblocks a waiter, if that waiter has a higher priority than the broadcaster, it preempts immediately.

Since the broadcaster's iterator hasn't advanced yet, the preempting thread consumes the message, loops back, and re-queues itself _behind_ the current iterator position. When the broadcaster finally resumes, it sees the 'new' waiter and wakes it again, creating the cycle.

To fix this without disabling thread dispatching (which defeats the purpose of SMP), I propose implementing the **Generation Counter** strategy discussed earlier:

1. Add a `generation` counter to `Message_queue_Control`.
2. Capture a snapshot of this generation at the start of the Broadcast call.
3. During the wake-up loop, verify that `waiter->generation <= snapshot`. Any thread with a newer generation (i.e., one that re-queued during the broadcast) is skipped.

I am currently working on a reproduction case in `psxtests` to force this specific preemption scenario and confirm the fix.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4804#note_142819
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260216/43d176fd/attachment.htm>