On 11/02/21 5:10 am, Levente Uzonyi wrote:
> IMO, the ideal solution would be to
> 1. Make sure that #yield lets all existing higher priority processes run 
> besides all the same priority processes
all existing *equal* or higher priority ...

yield just surrenders the time slot ahead of its expiry. The active 
process is moved to the back of its priority queue for #reschedule.

> 2. When #priority: is sent to the active process to decrease its 
> priority, then that process should
>      a) should keep running without interruption if there's no higher 
> priority processes awaiting execution than the new priority
>      b) should be suspended if there are higher priority processes ready 
> to run, and it should be resumed once all higher priority processes are 
> suspended or terminated.
Rescheduling logic should be separated from priority setting logic. 
#priority: should simply switch the process from its existing priority 
queue to the back of the new priority queue and then #reschedule. #yield 
reduces to setting a process to its current priority. It gives an 
opportunity for rescheduling.

#reschedule logic should pick the next process to run. If this happens 
to be same as active process, no further change is required. Otherwise, 
the active process is suspended and the new process resumed.

The third case when rescheduling is requested is by an async event like 
timer, interrupt, input etc. Here if the active process has exhausted 
its time slice, then it should be forced to #yield (fair share policy).

Rescheduling a process is quite tricky. The working priority used in 
scheduling decisions could be different from that of a process's 
priority setting. Sometimes, a process (A) could be holding a mutex on 
which a higher priority process (H) is blocked. In this case, A's 
working priority is the highest priority of its waiters.

HTH .. Subbu