Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 23, 2018 5:42 am wrote:
>
> In my ignorance, I thought that the OS could simply check if the thread yielded shortly after
> it was given some extra time and if not penalize the thread (adding the extra time slice to its
> use count would be a light punishment, revoking the privilege would be a heavier punishment).
> The thread would only get one extension when another thread would ordinarily be scheduled.

.. so what about realtime? Just throw that out the window?

What about page faults that need to do IO?

What about any number of things that simply force the process to be scheduled?

And since you have to force-evict at some point anyway, whatever issue you tried to prevent is still there, and so the process can't rely on it anyway.

So it's completely idiotic and pointless. All you added was a grace period non-guarantee that doesn't guarantee anything at all, but that made people perhaps think it did, and probably incorrectly rely on it.

If you don't see why that is stupid, I can't help you.

> (Policed cooperative multitasking seems like a potentially useful design.)

Oh, cooperative scheduling within a group of mutually trusting threads can be great. It means they don't need any locking amongst themselves, and they could have some fixed thread-pool or whatever. I'm all for it, and it's been done (often in user space).

It doesn't have anything to do with percpu state and some general operating system interfaces.

> > Don't do it. There is no upside anyway.
>
> In my ignorance (I am not even a programmer much less an operating systems developer), I thought
> that there were cases where temporary deadlock due to thread scheduling was a significant issue.

Oh yes. Locking is complicated. But "let the processes tell you that they want to run longer" isn't the answer.

Linus