David Hess (davidwhess.delete@this.gmail.com) on September 13, 2021 3:28 pm wrote:
> Doug S (foo.delete@this.bar.bar) on September 13, 2021 3:05 pm wrote:
> >
> > Allowing apps to determine where their threads should run would be like turning back the
> > clock to the cooperative multitasking days. You have to rely on all apps being "good citizens"
> > which is simply not realistic. Even if you 'reviewing' apps manually like Apple you can't
> > possible test all the corner cases, and do a full re-test for every update.
>
> In my post, I almost made the comparison with cooperative multitasking
> but thought it might be a little too much. :)
>
> The hard real time operating systems that I am familiar with only
> manage it with considerable input from the application developer.


In some ways this problem is sort of like that faced by hard real time systems, and the solution is probably similar. A deadline scheduler that allows the application to say "I need this done by time X" where X might be before the next screen refresh or before the arrival of the next data block from storage could let the application communicate what it needs and allow the OS to determine the best way to make that happen.

You still have the same problem, if an app always says "I need this done ASAP" for everything, but that's less likely since the app will have things dependent on human response time, on something coming from the internet, etc. There's nothing to be gained by requesting minimum latency, so long as you trust the scheduler to meet the deadline.

The nice thing is that unlike a hard realtime system a smartphone's deadline scheduler wouldn't need to ALWAYS get it right. If fails to meet the deadline once in every 10,000 times it isn't going to be a big deal. Maybe you see a slight screen tear in a game once every few hours, that's acceptable for a smartphone unlike say an automotive ECU or the system that operates the control surfaces of a modern aerodynamically unstable fighter jet.