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

[Martin Werner (@martinerikwerner)]

Martin Werner commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4804#note_135155


Related to this, in https://lists.rtems.org/pipermail/devel/2023-February/074400.html, Sebastian Huber noted:
> Thanks for the updated documentation. It let me think about the current
implementation since the current behaviour is a bit scary.
> 
> In uniprocessor configurations, the current behaviour could be fixed by
disabling thread dispatching for the entire broadcast. This should be
acceptable. The disabled thread dispatching prevents that new waiting
threads show up in the queue.
> 
> In SMP configurations, this is not sufficient (new waiting threads can
show up on other processors). We could add a 32-bit generation number to
the message queue. When a waiting thread is enqueued, it increments and
gets the generation number. In the broadcast we dequeue only threads
with a generation number less than the one at broadcast start (modulo
operation).

(The suggested documentation update was not added at the time.)

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4804#note_135155
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/20251018/861dd464/attachment.htm>