RTEMS | SMP: Add FMLP-Short and FMLP-Long locking protocols (!882)

[Gedare Bloom (@gedare)]

Gedare Bloom started a new discussion on cpukit/include/rtems/rtems/attr.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_148517

 > +#define RTEMS_FLEXIBLE_MULTIPROCESSOR_LOCKING_LONG 0x00000400
 > +
 > +/* Generated from spec:/rtems/attr/if/flexible-multiprocessor-locking-short */
 > +
 > +/**
 > + * @ingroup RTEMSAPIClassicAttr
 > + *
 > + * @brief This attribute constant indicates that the Classic API semaphore
 > + *   created by rtems_semaphore_create() shall use the Flexible Multiprocessor
 > + *   Locking Protocol - Short variant (FMLP-S).
 > + *
 > + * @par Notes
 > + * The FMLP-S uses non-preemptive execution for short critical sections. The
 > + * semaphore shall be a binary semaphore (#RTEMS_BINARY_SEMAPHORE).
 > + */
 > +#define RTEMS_FLEXIBLE_MULTIPROCESSOR_LOCKING_SHORT 0x00000200

I'm contemplating the API ramifications of this change. While we have supported MrsP for quite some time, there are certainly several kinds of multiprocessor protocols. I wonder if we need to have a roadmap and plan to make sure we are being thoughtful about how we accept these as they commit us to API. In this case, the attribute field becomes something we have to support into the future.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_148517
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/20260413/31670467/attachment-0001.htm>