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

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 11 07:02:42 UTC 2021


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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210210/f5de6b67/attachment.html>


More information about the Squeak-dev mailing list