Hi everyone,
I’m interested in the “Message Queue Improvements and Fixes” GSoC project and have been investigating one of the linked issues: POSIX Message Queue thread release order is not priority based(#3791). I’m using RTEMS 7 with the erc32-sis BSP.
Initial Problem
According to the POSIX specification, when multiple threads are waiting to receive a message on a message queue and a message arrives, the thread of highest priority that has been waiting the longest should be selected. However, in my initial tests I observed FIFO behavior (low priority thread woken first) even though I assumed the queue was configured correctly.
Modification Made
After reviewing the code, I found that in cpukit/posix/src/mqueueopen.c, inside the function _POSIX_Message_queue_Create(), the core message queue discipline was set to CORE_MESSAGE_QUEUE_DISCIPLINES_FIFO. I changed it to CORE_MESSAGE_QUEUE_DISCIPLINES_PRIORITY. This ensures that the underlying core message queue uses priority-based thread waiting queues.
Verification
To verify the effect, I wrote a test program (posix_mq_priority_wakeup_test .txt (6.4 KB)
) that:
- Creates a POSIX message queue with default attributes.
- Creates two threads: one with POSIX priority 20 and one with POSIX priority 10.
- Uses two independent binary semaphores to control the order in which the threads enter
mq_receive()(the lower priority thread blocks first, then the higher priority thread blocks later). - Sends a single message and records which thread receives it.
After applying the fix, the test output shows correct behavior:
Release low priority thread
Thread POSIX prio 10: RTEMS prio 245, blocking on mq_receive()…
Release high priority thread
Thread POSIX prio 20: RTEMS prio 235, blocking on mq_receive()…
Before sending: msgs=0
Send first message: Hello
Thread prio 20: received message: Hello
PASS: High priority thread received first message (priority order)
Conclusion
The issue is resolved by this one-line change. I believe this fix should be merged to ensure POSIX compliance. I would be happy to provide a proper patch and update the issue status.
@gedare @JoelSherrill Looking forward to any feedback. Thank you!