Overview
This thread is a technical log for my work on Issue #4612
My goal for GSoC 2026 is to implement and verify high-performance locking protocols for the RTEMS 7 SMP SuperCore.
While I am currently starting with the Flexible Multiprocessor Locking Protocol (FMLP), I plan to use the summer to master SuperCore internals and port as many protocols from the research collective as possible.
Prerequisite Homework: MrsP Analysis
Before jumping into new code, I verified the existing MrsP implementation using the smpmrsp01 test suite on the SIS/Leon3 simulator.
- The Experiment: I modified the
init.c taskset to set the main task priority to 1 and the MrsP priority ceiling to 5.
- The Result: This mismatch triggered a terminal assertion failure at line 1411 in the
mrsp_obtain_and_release_with_help.
- The Finding: Analyzing the switch logs showed exactly how strictly RTEMS 7 monitors task-to-processor affinity and priority elevation.
- Why it matters: This gave me the hands-on experience needed with modern SuperCore primitives like
Thread_queue and ISR_Lock before starting the FMLP port.
Current Status: Porting FMLP (MR !882)
I have a functional port of FMLP that modernizes the original research code to align with the RTEMS 7 architecture.
- SMP Safety: All state transitions now use
Thread_queue_Context for atomic operations across cores.
- Wait Discipline: I’ve implemented strict FIFO wait queues for both Short and Long variants to ensure predictable behavior.
- API Support: Updated the Classic API Semaphore Manager so users can select the new
RTEMS_FLEXIBLE_MULTIPROCESSOR_LOCKING_SHORT and LONG attributes
- Observability: Patched the system monitor (
mon-sema.c) so FMLP semaphore types actually show up during debugging.
- Testing: The implementation is currently green on the
spfmlp01 (Long) and spfmlp02 (Short) test suites.
Recent Refinements
I’ve been working through initial community feedback to make the code upstream-ready:
- Commit Structure: I separated the work into an “Import” commit for the original research and a “Port” commit for my RTEMS 7 adaptations.
- Code Quality: I’ve cleared out formatting and whitespace issues across the core logic and tests.
- Licensing: Verified that the original research authorship and copyrights are correctly preserved.
Merge Request: !882
Project Issue: #4612
Update: Author Validation & Technical Refinements
I have attached an architectural review concluded with the original FMLP researchers, Dr. Kuan-Hsun Chen and Dr. Junjie Shi. Based on their feedback regarding edge cases and protocol semantics, I have pushed several final refinements to Merge Request !882:
- Academic Validation: Dr. Chen validated that the mapping of FMLP-Long to modern
Thread_queue_Context state transitions is conceptually sound for SMP safety.
- New Test Suite (spfmlp03): I added a third regression test to address potential corner cases where multiple tasks share the same priority or ceiling values.
- Dynamic Scaling: I replaced hardcoded limits in FMLP-Long with
Scheduler_Count and Thread_priority_storage to ensure the implementation scales dynamically with the system configuration.
- Bug Fixes: Corrected a ceiling override in FMLP-Short to ensure it strictly respects the priority passed via the API.
- Formal Verification: Following Dr. Shi’s recommendation that regression tests alone may miss subtle synchronization race conditions, I have integrated a Promela/SPIN verification plan into my GSoC proposal.
FMLP_Architectural_Review_Karthikey_Kadati.pdf (113.6 KB)
Current Work in Progress: I am currently re-syncing the documentation and rtems-central YAML specs to reflect these latest architectural changes. While those specific repositories are being updated to match the new dynamic scaling logic, the core protocol implementation in !882 is ready for review.
Current Status: Moving forward with the implementation of Distributed FMLP (DFLP) as the primary focus of my GSoC 2026 application, as suggested by Dr. Chen.
Hey @gedare , I’ve finalized my GSoC 2026 proposal: (Doc Link).
I’ve integrated the feedback from the FMLP authors regarding dynamic scaling and formal verification. I would appreciate a technical review of the DFLP migration plan from you or anyone else on the team whenever you have a moment. Thanks!
I’ve finished syncing the rtems-central YAML specifications and the rtems-docs documentation with the final FMLP implementation changes.
I did a strict mapping of the FMLP-S (sticky busy-wait) and FMLP-L (priority inheritance) state transitions, and the generated SMP validation tests are now compiling and passing cleanly. While doing the validation runs, I also pulled out a few pre-existing -Werror fixes into their own separate MR so they wouldn’t clutter up the main review.
The implementation (!882), specifications (!15), and documentation (!206) are all fully aligned now and ready for review!
1 Like