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.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to