Alternative Thread Schedulers

J J azreal1977 at hotmail.com
Wed May 30 06:08:43 UTC 2007


>From: tim Rowledge <tim at rowledge.org>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Alternative Thread Schedulers
>Date: Tue, 29 May 2007 13:48:07 -0700
>
>I think you'll find that ProcessScheduler already does this.

I don't understand what you mean by this.  What I wanted to try was to 
create an alternative scheduler but without replacing the existing one (at 
least until I'm positive it is an improvement).

>Look in the MessageName browser for messages contaiing 'wait'.  There's a 
>gazillion.

I didn't see anything that would put the process to sleep for the specified 
amount of time or until the first yield situation (i.e. wake me on either of 
these conditions).

John gave a very nice write up of how the scheduling works.  What I did not 
see was how to hook into it from Smalltalk.  For example, if you call 
suspend, which calls primitiveSuspend the VM calls transferTo: and 
wakeHighestPriority but where does this come back into Smalltalk for 
handling?

What I want to do is from a higher priority process to take total control of 
the scheduling and try out an event driven style scheduler.  To be more 
specific, I would have, to start say, 6 different priorities: 1 real-time 
and 5 "normal".  Real-time runs any time it wants for as long as it wants, 
but the rest have a specific quantum.  The highest normal priority might 
have e.g. 20ms or maybe even just 10.  The lowest might have 250ms or maybe 
even 400 (I believe this is what sun gave their lowest priorties).  Of 
course tunning would be required with this.

If no real-time processes want the CPU then the highest normal process is 
run with something like:

nextProcess resume. "I'm assuming this doesn't start him until I, the high 
high prio process sleep"
self waitMilliseconds: (Process quantumsFor: nextProcess priority).

Then if the process yields the CPU in some way it goes up in priority.  If 
it uses the entire quantum then it is dropped in priority.  But for this to 
work I would need my new scheduler class to get involved any time there was 
some kind of context switch.  It can't happen that when the wait is over my 
process comes alive to find a different process is current then what he 
expects.

So what's the point?

Well, I see people on the list always saying to use Comanche as little as 
possible because it is too slow, but I wonder why this is the case.  Yaws 
(the Erlang web server, which spawns one new process per connection) beats 
Apache quite handily, I wonder why Comanche couldn't do the same.

I read on the Wiki that Comanche also forks a new process for each new 
connection, but from what I could tell it looks like the fork is at the same 
priority of the server.  So what this would mean is if 30 clients connect 
right after each other, 29 fast clients and one that requires a lot of 
processing then the clients will connect and be serviced until the 1 long 
one hits, then the rest have to wait for him to finish.

With the event driven scheduler described above each thread would be started 
in the highest priority with the lowest quantum (since the server spends the 
vast majority of his life sleeping he will quickly be promoted to top normal 
priority).  So the first quick processes connect, make their request and 
yield before using their quantum.  The long process would run out his entire 
10 or 20ms quantum and get demoted, allowing all the rest of the process to 
come in and be processed before he runs again.

Now the long process would actually take longer in this case, but more 
different clients are serviced in the same time making the server at least 
appear more responsive.

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507




More information about the Squeak-dev mailing list