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