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?