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

Levente Uzonyi leves at caesar.elte.hu
Thu Feb 11 19:24:33 UTC 2021


Hi Eliot,

On Wed, 10 Feb 2021, Eliot Miranda wrote:

> Hi Levente,
> 
> On Wed, Feb 10, 2021 at 3:41 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       Hi Eliot,
>
>       On Wed, 10 Feb 2021, Eliot Miranda wrote:
>
>       > Hi Levente,
>       >
>       > On Wed, Feb 10, 2021 at 11:54 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       >       On Wed, 10 Feb 2021, Eliot Miranda wrote:
>       >
>       >       >
>       >       >
>       >       > On Wed, Feb 10, 2021 at 11:27 AM Jaromir <m at jaromir.net> wrote:
>       >       >       > the right solution is to create a new primitive if we want to support
>       >       >       on-the-fly priority changes.
>       >       >
>       >       >       The system already does on-the-fly priority changes - implementing
>       >       >       #valueUnpreemptively and #valueAt: - but they're actually not working
>       >       >       properly due to this #priority: issue - they're trying to use #yield after
>       >       >       changing the priority down but that really doesn't do anything.
>       >       >
>       >       >
>       >       > So it seems to me that updating the yield primitive to "do the right thing" is a good way to go.  Agreed?  If so, I should be able to get to that very soon.
>       >
>       >       I think it's not. Let's say the priority of process p is 30, I want to
>       >       increase it to 40 and then do something at that priority.
>       >       #yield will stop the process and put it at the end of the list of
>       >       processes with 40 priority (I think the current implementation doesn't
>       >       check for priority changes and puts the process on the list of its
>       >       earlier priority).
>       >       So, with yield, p will have to wait until all other 40 priority processes
>       >       finish their job or yield instead of just continuing as the active
>       >       process.
>       >
>       >
>       > But if that's the behaviour you want you can either
>       > - set the priority, do the processing, and then invoke yield
>       > - do the processing and then set the priority and then yield, right?
>       >
>       > We're not tying assigning to priority to the yield primitive, right?  These are still distinct operations.  I'm simply suggesting that the yield primitive take into account the receiver's priority, which it currently doesn't do.
>
>       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.
> 
> 
> Agreed.  This means that yield should check to see if there is a runnable process at higher priority than the current process.  It doesn't do this.  It merely checks if there are processes at the same priority as the receiver.

#yield doesn't check for higher priorities because no higher priority 
process should ever be ready to run when #yield is sent.
The problem only occurs when the active process's priority is decreased 
and there is a higher priority process awaiting execution.

So, IMO, the right solution is to create a new primitive to set the 
process priority.
When it is changing the active processes priority and the priority is 
decreased then look for higher priority processes awaiting execution. In 
other cases, just set the value of the instance variable.


Levente


>       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.
>
>       Only fixing #yield does not help with the requirements in point 2.
> 
> 
> 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?
>
>       Levente
>
>       >
>       >
>       >
>       >       Levente
>       >
>       >       > _,,,^..^,,,_
>       >       > best, Eliot
>       >       >
>       >       >
>       >
>       >
>       >
>       > --
>       > _,,,^..^,,,_
>       > best, Eliot
>       >
>       >
> 
> 
> 
> --
> _,,,^..^,,,_
> best, Eliot
> 
>


More information about the Squeak-dev mailing list