RTEMS | Lower Message Priority Range Supported by POSIX Message Queues (#5247)

[Chandan U (@Chandanuvm)]

Chandan U commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5247#note_147026


Hello @gedare @joel ,

After studying the relevant code files and understanding the present priority bucket + bitmap implementation logic in the schedular,

I've created a draft MR ([!1164](https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164)) for POSIX priority message queue insertion/deletion algorithm optimization based on the discussions ([thread](https://users.rtems.org/t/gsoc-26-lower-message-priority-range-optimization/496)) and findings.

Explanation of the draft design and Implementation:

* In `coremsg.h` which consists of message queue main internal structure , 
  * **new addn :** It extends `posix_priority` pointer , which makes the queue to optionally hold optimization state and NULL means fallback to legacy path
* In `coremsgimpl.h` which consists of the prototype of internal implementation
  * **new addn :**
    * `CORE_message_queue_Posix_priority_context` structure:

      \- bitmap 

      \- per-priority bitmap info 

      \- per-priority chain buckets 
    * declaration for `_CORE_message_queue_Enable_posix_priority_buckets() `
    * fast path in pending-message retrieval using bitmap.
* In `mqopen.c` which consists of POSIX specific create/open logic
  * **new addn** : calling the enable function for priority bucket+bitmap
* In `coremsg.c` which consists of logic related to queue initialization and setup
  * **new addn** :  implementation of the enabling function
* In `coremsgflush.c` which consists of the logic to clear all the pending messages
  * **new addn** :  flush helper for priority bucket and bitmap reset
* in `coremsginsert.c` which consists of the actual O(n) algorithm , for the insertion of priority messages
  * **new addn** :  append to corresponding bucket  and set bitmap bit

With this I've also created a small draft benchmark for comparing the before and after optimization paths  MR (!1151)

* **Logic:** Inserting same priority messages and filling the message queue to its limit, a receiver thread is called and made the queue to get free by exactly one space, then a sender is called to insert the message with same priority which is already present in the queue (to make sure that it traverses to the end of the queue) using `rtems_counter_ticks` and `rtems_counter_read()`.  

I would be grateful for any feedback or suggestions on the design and implementation.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5247#note_147026
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/20260325/45c49204/attachment.htm>