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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
