<div dir="ltr">Hi<div><br></div><div><div style="font-size:12.8px">I am new to Litmus and I am now trying to implement the MrsP under P-FP.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Currently I have two  questions:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1. I've been reading your litmus report (a very long one) and notice you said </div><div style="font-size:12.8px"><br></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px">" In our experience, handling suspending and resuming processes is a common source of errors. A process may suspend and be resumed again almost immediately thereafter before a context switch can occur (e.g., this is the case for many page faults, and especially those due to copy-on-write semantics). In the past, novice developers have commonly disregarded the possibility of such “quickly resuming” processes, which may result in ready processes failing to be enqueued in a ready queue (in which case they are never scheduled again and become “stuck”) or in being wrongly enqueued twice (which crashes the kernel eventually). Besides migration support (see Section 3.3.4 below), races related to short suspensions have in our experience been the most common cause of crashes in LITMUSRT. "<br><br></blockquote><span style="font-size:12.8px">And this is exactly the problem that I am now experiencing. </span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I tired to implement the MrsP protocol under the P-FP scheduler and developed a test program in user space to test. However, The program sometimes stuck because the lock holder is blocked but not rescheduled (mostly when trying to print by printf).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I wonder, how to prevent such races from happening? Will printf be problematic in used in Litmus real-time thread with a very short period (say 1ms). </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2. MrsP defines that if a lock holder is preempted, It can migrate to any processors that has a waiting (spinning) task on it. Yet as I am trying to implement MrsP under P-FP, there is no support for choosing the most most suitable cpu among all the cpus the preempted task can migrate to. I wonder do you have any suggestions for building a mini migration routine for F-PF or could I use any facilities to achieve this from either Linux or Litmus?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I also notice that the sched_setaffinity is disabled by litmus as it could introduce unbounded priority inversion. However, I wonder how can I use this function again in Litmus RT tasks if I do not care the drawback it carries.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thank you in advance.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Best wishes</div></div></div>