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

[Joel Sherrill (@joel)]

Joel Sherrill commented on a discussion on cpukit/include/rtems/rtems/attr.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_151697

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

Consideration of API ramifications is part of the high level items that need considering. Once something is added to RTEMS, it is hard to remove. We consciously avoid breaking backwards compatibility. 

The first question is more of a filter: "Is this academically solid?" I think the answer to that must be "yes" or this would not be so far along. Here are some others considerations (in no particular order): 

- This will need 100% coverage tests.
- This may need configure ini options.
- This may need confdefs.h configuration options.
- It will require user facing documentation.
  - Documentation should include guidance on when to use this or alternatives or none.
- User facing examples (not tests)
- Does it impact code size for non-SMP builds?
- Is the code included in all SMP builds even if not used?
- Does this require any reporting APIs or debug support?
  - If one were to inspect an application running, what would they need to see?

As to the specific attribute bits:

- Would we want to support more than one protocol per RTEMS build? Would you use different protocols on different mutexes?
  - Can we reduce this to one protocol per build? Does that make sense?
- RTEMS attributes are not semaphore specific. Any changes have to avoid conflicting with bits used by other objects.
  - Could it be a 2 or 3 bit wide field with a number rather than 3 yes/no choices. I don't think you can use multiple protocols on a single object instance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/882#note_151697
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/20260603/6a486a74/attachment-0001.htm>