Help with threads
tim Rowledge
tim at rowledge.org
Mon Jan 23 05:47:43 UTC 2006
On 22-Jan-06, at 4:40 PM, Ron Teitelbaum wrote:
>
> The comments on Processor>>yield says use to allow processing on a
> process
> with the same priority. Why is it that this didn't work even
> though they
> are not the same priority? Since A thread is at the active
> priority, and B
> and C are at background, wouldn't a yield on A allow processor time
> to B and
> C? (I'm assuming that there are no other higher priority threads
> running,
> since even debugging allows the threads to finish). I was calling
> yield
> once each check loop. What process was it yielding to?
The yield gives other processes at the same priority a chance to run,
nothing more. If there are not any waiting processes in the same
priority, nothing changes.
Now, one needs to temper that statement a little with the rarely
mentioned basic assumption built deep into the VM that a high
priority process will pre-empt any lower priority at any message send
or backward branch bytecode (added so that tight loops shouldn't
screw us up) in order to get the full story. Actually these days the
check is done every few thousand message sends or so since we enjoy
considerably faster machines (in most cases) that used to be the
case. In an ideal world there would be a nice way to interrupt the
interpreter loop rather than essentially polling for something
awaiting attention.
The only way to give a low priority process a chance to run is to put
any and all higher priority processes to sleep for a while which
removes them from the 'ready to run' lists which is why using a wait
works for you. Waiting for a Delay or waiting for a semaphore signal;
either will work.
>
> I like the idea of maybe changing the controller to check processes
> that
> want control and then use the controller loop time to bump up their
> priority
> to give them some processor time. Is that a good way to manage
> scheduling
> time? How responsive are the threads to changes in priority?
Ah, good question. I think the only way you would get any real effect
from changing the priority of a running or quiescent process would be
to sleep it and reawaken it after the priority change. If you look at
the Process>priority: method you'll see that there is nothing done to
move the affected process around in any processor queues. Maybe that
should be changed.
tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A)bort, R)etry or S)elf-destruct?
More information about the Squeak-dev
mailing list
|