[squeak-dev] The Inbox: Kernel-jar.1368.mcz

Jaromir m at jaromir.net
Thu Feb 11 09:27:11 UTC 2021


Hi,

> The current issue is that when a process's priority is decreased, e.g.
> from 42 to 40, and there's a process waiting to be executed at priority
> 41, then that process will not be activated but the process with priority
> 40 will keep on running.
> And, even yielding after the priority decrease doesn't help now.
>
> 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.
> 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.


(b) is still unclear to me: if you decrease an active process's priority
from 42 to 40 and there's a process waiting at 41, AND there's another
process waiting at 40 then: the active process should suspend, the process
at 41 should run and then what: resume your original process or run the
other waiting process at 40 first?


> Ah, yes, I see. That's tricky.  "Fixing" yield to ensure that the highest
> priority process is runnable and using it in Process>>priority: would have
> the unwanted side-effect of yielding.  So we may need another primitive. 
> A primitive that answered the highest runnable priority process would
> work.  Then we could write
>
> Process>>priority: anInteger
>     priority := anInteger.
>     ProcessorScheduler highestPriorityRunnableProcess priority > priority
> ifTrue:
>         [self yield]
>
> That would be OK right?

If the process should run before other processes waiting at its new
(decreased) priority then #yield would still send the process to the end of
the 40 queue, right? 

Btw, there's already a #nextReadyProcess method available but non-primitive
so understand it's not usable for the above purpose as such.

The condition above should apply to the active process only, is that right?

Process>>priority: anInteger
	priority := anInteger.
	self isActiveProcess and: [Processor nextReadyProcess priority > priority]
ifTrue: ...

best,
Jaromir




--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list