RTEMS | SMP: Add support for the MPCP locking protocol (!1358)

[Ivy Zhuang (@purple-affogato)]

Ivy Zhuang commented on a discussion on cpukit/include/rtems/rtems/attr.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1358#note_155059

 >   */
 >  #define RTEMS_MULTIPROCESSOR_RESOURCE_SHARING 0x00000100
 >  
 > +/**
 > + * @ingroup RTEMSAPIClassicAttr
 > + * 
 > + * @brief This attribute constant indicates that the Classic API Semaphore
 > + *   created by rtems_semaphore_create() will use the Multiprocessor Priority
 > + *   Ceiling Protocol.
 > + *
 > + * @par Notes
 > + * The semaphore instance must be a binary semaphore (#RTEMS_BINARY_SEMAPHORE).
 > + */
 > +#define RTEMS_MULTIPROCESSOR_PRIORITY_CEILING 0x00002000

In terms of multiprocessor locking protocols, it doesn't really make sense to use more than one variant per application. From what I've seen, locking protocols tend to assume certain circumstances to do with scheduling, fixed/dynamic task priorities, task allocation, etc. to be ideally increase schedulability, making them incompatible with one another.

I recall in !882 Karthikey suggests using a locking protocol mask that takes 2-3 bits instead which I think could work well. The attribute set used for `rtems_semaphore_create()` would probably remain unaffected as well.

Another option would be to add a configuration option that lets you choose the SMP locking protocol so the protocol information would be stored elsewhere. This would then limit you into choosing to use only one protocol if RTEMS_SMP is defined. 

I'd be interested in hearing what the community thinks is the better option though.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1358#note_155059
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-187jwi6jrk3ktb0bqju9extyc-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260722/4cd93ad0/attachment-0001.htm>