Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 21, 2018 2:34 pm wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 21, 2018 9:09 am wrote:
[snip]
> > Since threads have phases that benefit from not being significantly interrupted, I think there
> > would be value to allowing a thread to express that a phase would extend beyond the normally
> > allotted time slice
>
> No.
>
> People will just misuse that, and then you need a lot of BS code to prevent misuses etc.

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.

A thread would have to check if it had been given extra time earlier in the time slice before acquiring a (significant) lock and yield (with the possibility of being scheduled immediately and acquiring the lock since the check would now pass). (This would add the overhead of loading the flag value and branching and an unnecessary system call if the privilege had been used in the time slice but now the thread gets a time slice anyway when earlier it would have been descheduled.) (Hardware support for marking phases might be useful in lowering overhead and providing information to the microarchitecture.)

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


> 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.