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

[Karthikey Kadati (@karthikey_kadati)]

Karthikey Kadati commented on a discussion on cpukit/include/rtems/rtems/attr.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_148558

 > +#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

Fair point, merging this means a long-term commitment to support these protocols, and I also want to make sure the attribute field doesn't get cluttered with too many one-off bits.

What I'd like to do is introduce a `RTEMS_LOCKING_PROTOCOL_MASK`similar to how `RTEMS_SEMAPHORE_CLASS (0x00000030)`names the semaphore-type bits. The mask would cover MrsP's existing bit plus the new FMLP ones. No existing values change--it just gives the protocol bits an explicit name instead of the manually maintained OR-list in `_Attributes_Has_at_most_one_protocol()`. When DFLP (or another protocol )comes later, it slots into the mask instead of being another ad-hoc addition.

On the protocols themselves: FMLP comes from well-established real-time literature (Block et al., 2007) and is already in LITMUS^RT. The implementation follows the same pattern as MrsP, so maintenance overhead should be minimal. DFLP is next as part of my GSoC, and that's the full scope.

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