This topic is an extension of the Locking Protocols for Multiprocessors project idea. I noticed that support for FMLP is already being implemented, so I hope I’m not stepping on any toes by expressing interest in this project 
. I’ve read through the research paper & issue page, and here are my thoughts so far:
MrsP testsuite → Ran into some troubles here, currently getting fatal code 30 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL) on smpmrsp01 in the deadlock error test with aarch64/zynqmp_qemu. Not sure if I should open up an issue on GitLab since I don’t know if it’s a problem with the test itself. My initial idea was that finding a fix to the fatal error could fulfill the requirement of making a change to the taskset, but I thought would ask about it first since it can be due to outside causes and I haven’t had the chance to debug it just yet.
MPCP & DPCP → From what I’ve read, these 2 protocols generally use the same idea of priority ceiling so it makes sense to implement them as a duo. I also think it would be beneficial to add the option of semi-partitioned scheduling to RTEMS. The first step would be to review this patch and make sure it integrates properly with newer versions of RTEMS. Any guidance on further steps regarding MPCP & DPCP is welcome, as I’m not sure if I should mainly work on writing up a proposal before putting contributing any code (plan-before-working sort of mentality).
Test Suite → The paper by Junjie Shi et al. mentions testing for overhead in regards to overhead, so I think it could be beneficial to introduce a set of tests that test for performance of the different protocols, which we can later evaluate how much overhead is acceptable. This could also be beneficial when making future changes to the locking protocols. I also plan on looking into what types of test cases are covered by the smptest tasksets and write up how to implement similar tests.
Sorry for the word dump, but I wanted to start a discussion-style thread for the project idea since the only other post I found on this seemed to be more of catalogue of that person’s progress. And as I mentioned above, I’m open to any suggestions on how I can get started and if there’s any holes in my thought process so far!
I’ll hopefully have a draft proposal ready after the weekend and I’ll add more research/progress to this thread 
Finding and fixing the error in smpmrsp01 would be a good task to work on to show some competency. If an issue isn’t open already, you can file one once you confirm the bug.
Performance measurement / benchmarking tends to be something that works best from outside of RTEMS, because we don’t want to run long-running tests as part of our regular test suite. There are some project ideas/discussions related to making our approach to benchmarks more consistent.
I did some debugging and opened up an issue for smpmrsp01 on GitLab. Still a bit confused as to what exactly caused the error, but I documented my findings in the issue’s summary.
1 Like
The next step would be to use git bisect to determine which commit introduced the failure. You can reduce your config to only build the SMPTESTS to make the bisect process a bit faster, if you decide to continue to investigate this.
Thank you for the advice! I’ll continue to investigate for now and see if I can find what’s causing the error. 
I was able to find the bug via git bisect! Turned out to be a pretty simple issue, and Sebastian Huber opened an MR on it faster than I could blink. I plan on focusing on completing my proposal in the meantime and hopefully have draft ready in the coming few days.
1 Like
Update on changing the MrsP testsuite:
I decided to try my hand at modifying test_mrsp_multiple_obtain(). The main idea of this test is to obtain and release multiple MrsP semaphores to ensure task priorities are managed properly after each obtain/release.
What I did was change the order that the task attempts to obtain semaphores so that it obtains higher priority semaphores first. This way, it would throw a RTEMS_INVALID_PRIORITY status code.
Here’s the code I changed:
// changes to the task set
sc = rtems_semaphore_obtain( sem_c_id, RTEMS_WAIT, RTEMS_NO_TIMEOUT ); // sem of prio 1
rtems_test_assert ( sc == RTEMS_SUCCESSFUL );
sc = rtems_semaphore_obtain ( sem_b_id, RTEMS_WAIT, RTEMS_NO_TIMEOUT ); // sem of prio 2
rtems_test_assert ( sc == RTEMS_INVALID_PRIORITY );
sc = rtems_semaphore_obtain ( sem_a_id, RTEMS_WAIT, RTEMS_NO_TIMEOUT ); // sem of prio 3
rtems_test_assert (sc == RTEMS_INVALID_PRIORITY );
sc = rtems_semaphore_release ( sem_c_id );
rtems_test_assert ( sc == RTEMS_SUCCESSFUL );
Hope this is enough to fulfill the requirement and include in my proposal.
@gedare
I’ve spent some time working on my proposal and I think it is ready to receive some feedback so I’m leaving a link here as I know you’re a potential mentor for this project.
No pressure to send feedback right away of course