RossBoylan at stanfordalumni.org
Tue Mar 29 16:56:39 UTC 2005
I think I've got it. This message is to confirm my understanding and
answer a few questions people asked me.
When Tim originally wrote
> There is a single active process and it runs until it stops. You can
> make it stop temporarily by deliberately yielding occasioanlly
this was a reference to the scenario where the active process had
priority greater than or equal to any runnable process. Further, the
deliberate yielding is only important for same-priority processes;
higher priority processes will run anyway, and lower priority
processes still won't run even if you attempt to yield to them (using
Processor yield--if you use a Delay or something else that actually
stops the current process, lower priority processess will get a chance
as long as no higher priority processes are runnable).
Originally I thought this meant that any process would run until it
stopped and would not give up control under any circumstances.
On Mon, Mar 28, 2005 at 09:28:24PM -0800, Tim Rowledge wrote:
> Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
> > I thought from earlier remarks (not by you) that even a lower priority
> > process could block a higher priority process, if the former did not
> > yield control.
> Higher priority processes that are in a runnablestate (ie not held back
> by a semaphore etc) will take control away from any lower priority
> process just as soon as they can. As John said, that opportunity comes
> with every message send and backwards branch bytecode, which is quite
> frequently. However, if a low priority process calls a very long
> running prim (right now any DNS related activity counts as a
> geologically long prim on my setup; damn telus DNS...) then you can be
> held up for a while. VW has some mechanism for combating this by ...
> well some means or other involving native threads.
So John's earlier statement that
> [P]rocessing switching can occur ....
> on a primitive call if when the call takes > 1 or perhaps 17ms
> depending on platform.
does not reflect current behavior?
> > Obviously if you have a lower priority (smalltalk) process a higher
> > priority process can block you, but I thought the problems did not end
> > there. Most of the comments in this email thread indicate that the
> > initial example of the email thread was a problem only because it was
> > running at a relatively high priority. But some of the comments
> > indicate the problem is the processor (as in processor vs email, not
> > as in the class Processor) thread is not yielding control,
> > regardless of its priority.
> Can't quite make out your point there, sorry.
Sorry to be unclear (Ned also couldn't follow). Rephrasing, it's
clear that higher priority processes can block lower priority ones.
But I read some of the comments (e.g., the quote from Tim at the top
of this message) as saying that a low priority process could block a
high priority one. My current understanding is that's not true
(unless there's a call out or a weird bit of code without message
sends or jumps back).
> > But below you say every method send is an opportunity to yield, so
> > explicitly coded yields seem unnecessary. More about this below.
> Recall that the process switch checking done in the VM only checks for
> a runnable _higher_ priority process.
This clarifies something for me: although the places in which a
process can yield occur frequently, yielding does *not* occur
automatically to same priority processes. This would be one reason to
code explicit yields.
> Not for other equal or lower
> priority ones. Yielding is needed if you want to 'play nice' and give
> other same-priority processes a go at the cpu; #yield puts the current
> process at the back of the right priority list and gets the one now at the
> front. This gives a sort-of round robin effect. It does nothing at all to
> help starving low class processes. To give lower priorities a go you have to
> suspend anything higher - make them wait on a semaphore with a short delay for
> I guess the good news is that pretty much everything is accessible and
> you could write a scheduler that would do pretty much anything you want
> by way of sharing the cpu out.
Was the decision not to implement a scheduling policy with ageing
(priority drops as a process runs; it rises the longer it has not run)
motivated by a desire for simplicity, or by some actual risks with an
P.S. Multiprocessor systems are becoming increasingly common. so that
would be one possible motivation for native threads.
More information about the Squeak-dev