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