<div dir="ltr">Good Evening,<div><br></div><div>My name is Robert, I'm a graduate student using LITMUS-RT to schedule my own real-time tasks for an experimental platform. I had a quick question on LITMUS's behaviour when a job misses its deadline and budget enforcement is enabled.</div><div><br></div><div>Some very quick background context:</div><div>Each of my real-time tasks is implemented using your great native C API for switching the task over from the Linux background scheduler to our own scheduling plugin. After releasing the task, we have a loop that executes the workload for each new job release, as recommended by your documentation, sleeping until the next release at the end of each loop.</div><div>Running some tests and looking through the kernel code, it appears that if the job were to miss its deadline, it would be preempted by the scheduler, log the job as having missed its deadline, and prepare the scheduler for the next immediate release while the user level task itself stays unaffected. When the next job is scheduled, the application resumes from where it was previously preempted, even though the kernel considers it a new job.</div><div><br></div><div>Is there a way to handle resetting the user level application from the top of the job's loop instead of having the next job resume from where the last one left off? It is important for us that each new job starts from the beginning. This seemed like a common scenario for hard real-time applications and I wasn't sure if I was missing something.</div><div>I imagine that a difficult part of handling this is ensuring that the state of the task's memory is consistent for each new job release and I don't know how the kernel would be able to handle resetting this for any generic application.</div><div>Thank you for your time as well as any and all assistance!</div><div><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Best,</div><div>Robert</div></div></div></div></div></div>