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

[Xinhong Hu (@aptacc2421)]

Xinhong Hu commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142751


Hi @gedare @joel

I'm interested in working on this issue as a part of GSoC. I've been doing some debugging on RTEMS 7 (erc32-sim) and can confirm the problem still exists. Here's what I've done:

**Initial observation:**

In _\`cpukit/posix/src/mqueueopen.c\`_ I change _\`CORE_MESSAGE_QUEUE_DISCIPLINES_FIFO\`_ to _'CORE_MESSAGE_QUEUE_DISCIPLINES_PRIORITY'_, but the behavior remained **FIFO** – a low-priority thread (20) blocked first, a high-priority thread (10) blocked second, and when a message was sent, the low-priority thread received it. My test code is below:

[posix_mq_priority_wakeup_test.c](/uploads/2399b615eea65119a9bd30d4ae1262f9/posix_mq_priority_wakeup_test.c)

**Verification:**

I added runtime prints in \`coremsgsubmit.c\` to confirm that the message queue operations are indeed set to priority versions:

> ops.enqueue = 0x2008f5c (priority_enqueue)\
> ops.extract = 0x2008a9c (priority_extract)

**Deep debugging with GDB:**

I used \`sparc-rtems7-gdb\` to set breakpoints in \`\_Thread_queue_Enqueue\` and \`\_Thread_queue_Extract_locked\`, printing thread priority via \`the_thread-\>Real_priority.priority\`. The output was:

> \[Enqueue\] thread addr: 0x02018408, priority: 490 (low-priority thread) 
>
> \[Enqueue\] thread addr: 0x02018c78, priority: 200 (high-priority thread) 
>
> ... 
>
> \[Dequeue\] thread addr: 0x02018408, priority: 490

This shows:

1. Enqueue order: low-priority first, high-priority second. 
2. Dequeue order: the first-enqueued (low-priority) thread is extracted → **FIFO** behavior, despite priority operations being used.

**Conclusion:**

The priority enqueue function (likely \`\_Thread_queue_Enqueue_priority\` or a macro expansion) is not inserting threads in priority order; it's simply appending to the tail.

**My question:**

I've looked for the implementation of the priority enqueue function but couldn't locate it. It might be hidden in macros or in \`threadqops.c\`. Could you point me to the exact file/function that needs to be fixed? I'd like to contribute a patch and use this as part of my GSoC proposal (project [#88](https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/88)).

Thank you for your guidance!

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142751
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/20260214/715a2382/attachment-0001.htm>