RTEMS | POSIX Message Queue thread release order is not priority based (#3791)

[Xinhong Hu (@aptacc2421)]

Xinhong Hu commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143086


Hi @joel , @gedare 

Thank you for the thoughtful discussion. I've been prototyping the per-instance approach Joel suggested: adding an RTEMS-specific field `mq_ispriority` to struct `mq_attr`. This allows each queue to independently choose FIFO or priority wake-up order, with a default of FIFO to maintain backward compatibility. My tests on RTEMS 7 confirm that setting `mq_ispriority = 1` correctly wakes a higher-priority thread that blocks later.

Regarding Gedare's point about application configuration: I think per-instance control already gives applications the ability to configure individual queues. However, to also support system-wide defaults, we could add a configuration macro in `<rtems/confdefs.h>` (e.g., `CONFIGURE_POSIX_MESSAGE_QUEUE_DEFAULT_DISCIPLINE`) that sets the initial value of `mq_ispriority` for queues created with a NULL attribute. This would allow integrators to change the global default without modifying each `mq_open` call, while still permitting per-queue overrides.

For my GSoC project, I propose to implement both the per-instance field and the global configuration option. The core deliverables would be:

1. Extend struct `mq_attr` with `mq_ispriority` (guarded by `#ifdef __RTEMS__`).  
2. Modify `mq_open()` to interpret this field and pass the discipline to the core message queue. 
3.  Add a configuration macro in `<rtems/confdefs.h>` to set the default discipline. 
4. Provide comprehensive tests and documentation. 

I believe this scope is manageable within the GSoC timeframe and fully resolves #3791 while offering flexibility for future needs. I'd appreciate your feedback on whether this plan aligns with your expectations. If you prefer a simpler approach (only per-instance or only global), I can adjust accordingly. 

Thank you for your guidance!

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143086
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/20260220/bcf1a1a5/attachment-0001.htm>