RTEMS | draft: Add POSIX msgq priority bucket + bitmap implementation (!1164)

[Chandan U (@Chandanuvm)]

Chandan U commented on a discussion on cpukit/include/rtems/score/coremsg.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164#note_148528

 >    Chain_Control Inactive_messages;
 >  };
 >  
 > +#if defined( RTEMS_POSIX_API ) && ( MQ_PRIO_MAX <= 255 )
 > +typedef struct {
 > +  CORE_message_queue_Control   Base;
 > +  Priority_bit_map_Control     Queue;

Hi @joel , thank you for the review. I completely understand the concern regarding the per instance memory overhead. I had proceeded with the bitmap approach based on the earlier [discourse Thread ](https://users.rtems.org/t/gsoc-26-lower-message-priority-range-optimization/496/3?u=chandanuvm)discussion with @gedare and @sebhub's recent approval of the memory tradeoff for the 32 priority limit.

But I agree that the array of Chain_Control instances makes the base MQ object too large per message queue instance.

I will pivot the design to use the Red-Black tree implementation as you and Sebastian initially suggested, I will use the existing red black tree in the kernel , and update the draft MR shortly. 

@joel @sebhub @gedare Can you please guide me through this since I've included bitmap + priority bucket implementation solution in the proposal, how should I go about it.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164#note_148528
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/20260414/f1899024/attachment-0001.htm>