Xinhong Hu commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142834 Hi @gedare, Thank you for your guidance and for pointing me to the User's Forum for GSoC discussions. I have moved the discussion there as requested. For full details, including the corrected test code and output, I have posted a comprehensive report in the User's Forum: [GSoC 2026 : POSIX Message Queue thread release order is not priority based (#3791)](https://users.rtems.org/t/gsoc-2026-posix-message-queue-thread-release-order-is-not-priority-based-3791/495) Following your suggestion, I traced the `mq_send` path and revisited my test logic. I realized my initial misunderstanding of the POSIX-to-RTEMS priority mapping led to a flawed test setup. After correcting the test to ensure the lower RTEMS priority thread (mapped from POSIX 10) blocks first and the higher RTEMS priority thread (mapped from POSIX 20) blocks second, the message queue **does** wake the correct higher-priority thread. The only necessary change to guarantee POSIX compliance is setting the discipline to `CORE_MESSAGE_QUEUE_DISCIPLINES_PRIORITY` in `_POSIX_Message_queue_Create()` within `mqueueopen.c`, which I confirmed in my latest tests on RTEMS 7. Thank you again for your help. Any further feedback would be greatly appreciated. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142834 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
