Smalltalk › Squeak › Squeak - Dev

Alternative Thread Schedulers

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

J J-6

Alternative Thread Schedulers

Hi all,

I just read http://wiki.squeak.org/squeak/5682 that Tim (I think it was)
mentioned, and found the part about doing alternative scheduling with a
higher priority thread interesting.

The question I had was, in the example it says the high priority process can
use Delay's to sleep while other processes are running, but what happens
when a process does IO? Doesn't that cause the process to yield?

What I am thinking is, if I were to make a scheduler process that manages
all running processes, how can he find out every situation where a process
yields in some way? It would be ideal if there was a Delay
millisecondsOrUntilInterupt: type message.

Thanks,
Jason

_________________________________________________________________
More photos, more messages, more storageget 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

Bert Freudenberg

Re: Alternative Thread Schedulers

On May 29, 2007, at 20:28 , J J wrote:

> Hi all,
>
> I just read http://wiki.squeak.org/squeak/5682 that Tim (I think it
> was) mentioned, and found the part about doing alternative
> scheduling with a higher priority thread interesting.
>
> The question I had was, in the example it says the high priority
> process can use Delay's to sleep while other processes are running,
> but what happens when a process does IO? Doesn't that cause the
> process to yield?
>
> What I am thinking is, if I were to make a scheduler process that
> manages all running processes, how can he find out every situation
> where a process yields in some way? It would be ideal if there was
> a Delay millisecondsOrUntilInterupt: type message.

What's the actual problem you want to solve with your alternative
scheduler?

- Bert -

J J-6

Re: Alternative Thread Schedulers

I just wanted to experiment with an event driven scheduler and see if it
makes any kind of difference in performance, especially in the case of many
concurrent processes.

>From: Bert Freudenberg <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Alternative Thread Schedulers
>Date: Tue, 29 May 2007 21:10:00 +0200
>
>
>On May 29, 2007, at 20:28 , J J wrote:
>
>>Hi all,
>>
>>I just read http://wiki.squeak.org/squeak/5682 that Tim (I think it was)
>>mentioned, and found the part about doing alternative scheduling with a
>>higher priority thread interesting.
>>
>>The question I had was, in the example it says the high priority process
>>can use Delay's to sleep while other processes are running, but what
>>happens when a process does IO? Doesn't that cause the process to yield?
>>
>>What I am thinking is, if I were to make a scheduler process that manages
>>all running processes, how can he find out every situation where a
>>process yields in some way? It would be ideal if there was a Delay
>>millisecondsOrUntilInterupt: type message.
>
>What's the actual problem you want to solve with your alternative
>scheduler?
>
>- Bert -
>
>
>

_________________________________________________________________
PC Magazines 2007 editors choice for best Web mailaward-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

timrowledge

Re: Alternative Thread Schedulers

In reply to this post by J J-6

On 29-May-07, at 11:28 AM, J J wrote:

>
> The question I had was, in the example it says the high priority
> process can use Delay's to sleep while other processes are running,
> but what happens when a process does IO? Doesn't that cause the
> process to yield?
Not as such, no. *IF* you implement the io in such a way that it can
be non-blocking (see the somewhat mouldy AsynchFile class for an
example) then you would indeed make the relevant thread/Process yield
by way of waiting on a semaphore.
>
> What I am thinking is, if I were to make a scheduler process that
> manages all running processes

I think you'll find that ProcessScheduler already does this.

> , how can he find out every situation where a process yields in
> some way? It would be ideal if there was a Delay
> millisecondsOrUntilInterupt: type message.
Look in the MessageName browser for messages contaiing 'wait'.
There's a gazillion.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CPM: Change Programmer's Mind

johnmci

Re: Alternative Thread Schedulers

In reply to this post by J J-6

I'm sure there was mail earlier asking about when a process switch
happens. Ok let's clarify that. There is only one place in the VM
where that happens is.

Interpreter>>transferTo:

called by

primitiveSuspend -> transfer to wakeHighestPriority
Called via Smalltalk Process>>suspend, Process>>terminate

primitiveWait -> transfer to wakeHighestPriority, unless
excessSignals is > 0, in that case we subtract one, and don't do the
transferTo:
primitiveYield -> transfer to wakeHighestPriority, and stick
current process on last link of queue in it's priority group.
resume: -> transer to given process if it has higher priority than
current process, and put current process toSleep:.
Otherwise if same or less prioirty put given process toSleep:

Called on a Semaphore signal via Interpreter>>synchronousSignal:
This ensures if the process is higher priority it will become un-
suspend and run, or
become un-suspended and be put on queue to run some day later...

I'll note the priority queue is a sorted list of linked lists.

Helper methods

toSleep: -> sticks process on last link of priority queue.

wakeHighestPriority -> fetchs the process that is runable that is
the highest priority. Ending of course with the lowest priority idle
loop process which is always runable. Failure to fine any runnable
process terminates the VM with an error.

Semaphores

There are semaphores that are signaled via checkForInterrupts which
we mentioned earlier that attempts to run every 1ms.

special semaphores are:
lowSpace Signal if space is low
interruptPending Signal if keyboard interrupt was done
TheFinalizationSemaphore, Signal if any GC Finalization needs to run.

The other two interesting semaphores are:

ExternalSemaphores, dual queue of semaphores set usually by plugins
that want to signal a semaphore. SocketPlugin is heavy user of this
logic. The reason for two queues
is one queue is active, the other is being processed, this
avoids (one hopes) a race condition between signalling and processing
because the VM has no
way to lock access to the queue with a thread safe access
method since that level of processor instruction support is not in
the basic VM.

TheTimerSemaphore, The Delay logic tracks when the next Delay will
fire, it feeds that information to the VM, checkForInterrupts by
waking up every 1ms then looks at the
request time, versus ms time, and decides if it needs to signal the
TheTimerSemaphore, which then waits up the process waiting on the
Delay.

CheckForInterrupts is run when

a) A method starts to run
b) When we do a long unconditional jump bytecode (#160-167) backwards.

However that is moderated by interruptCheckCounter which tries to
ensure not every call will result in a checkForInterrupts call.
As earlier discussed over the years
interruptCheckCounterFeedBackReset tries to moderate the setting of
interruptCheckCounter
to ensure for example a do:while: which would result in two (if not
more) checkForInterrupt calls on each loop, the fiddling with
interruptCheckCounter will try to
ensure checkForInterrupt is only called every 1ms.

We use the forceInterruptCheck to force a checkForInterrupt call,
that is done on finalization signaling, lowspace, become:,
incremental/full GC, exernal semaphore signalling, plus a few others.

On May 29, 2007, at 11:28 AM, J J wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

J J-6

Re: Alternative Thread Schedulers

Yea, that was me. I am still thinking about this. :)

And thanks for the write up! I will explain more my thinking in my response
to Tim.

Thanks,
Jason

>Ok let's clarify that. There is only one place in the VM where that
>happens is.
>
>Interpreter>>transferTo:
>
>called by
>
>primitiveSuspend -> transfer to wakeHighestPriority
> Called via Smalltalk Process>>suspend, Process>>terminate
>
>primitiveWait -> transfer to wakeHighestPriority, unless excessSignals
>is > 0, in that case we subtract one, and don't do the transferTo:
>primitiveYield -> transfer to wakeHighestPriority, and stick current
>process on last link of queue in it's priority group.
>resume: -> transer to given process if it has higher priority than
>current process, and put current process toSleep:.
> Otherwise if same or less prioirty put given process toSleep:
>
> Called on a Semaphore signal via Interpreter>>synchronousSignal: This
>ensures if the process is higher priority it will become un- suspend and
>run, or
> become un-suspended and be put on queue to run some day later...
>
>I'll note the priority queue is a sorted list of linked lists.
>
>Helper methods
>
>toSleep: -> sticks process on last link of priority queue.
>
>wakeHighestPriority -> fetchs the process that is runable that is the
>highest priority. Ending of course with the lowest priority idle loop
>process which is always runable. Failure to fine any runnable process
>terminates the VM with an error.
>
>
>
>Semaphores
>
>There are semaphores that are signaled via checkForInterrupts which we
>mentioned earlier that attempts to run every 1ms.
>
>special semaphores are:
>lowSpace Signal if space is low
>interruptPending Signal if keyboard interrupt was done
>TheFinalizationSemaphore, Signal if any GC Finalization needs to run.
>
>The other two interesting semaphores are:
>
>ExternalSemaphores, dual queue of semaphores set usually by plugins that
>want to signal a semaphore. SocketPlugin is heavy user of this logic.
>The reason for two queues
> is one queue is active, the other is being processed, this avoids
>(one hopes) a race condition between signalling and processing because the
>VM has no
> way to lock access to the queue with a thread safe access method
>since that level of processor instruction support is not in the basic VM.
>
>TheTimerSemaphore, The Delay logic tracks when the next Delay will fire,
>it feeds that information to the VM, checkForInterrupts by waking up every
>1ms then looks at the
>request time, versus ms time, and decides if it needs to signal the
>TheTimerSemaphore, which then waits up the process waiting on the Delay.
>
>
>
>CheckForInterrupts is run when
>
>a) A method starts to run
>b) When we do a long unconditional jump bytecode (#160-167) backwards.
>
>However that is moderated by interruptCheckCounter which tries to ensure
>not every call will result in a checkForInterrupts call.
>As earlier discussed over the years interruptCheckCounterFeedBackReset
>tries to moderate the setting of interruptCheckCounter
>to ensure for example a do:while: which would result in two (if not more)
>checkForInterrupt calls on each loop, the fiddling with
>interruptCheckCounter will try to
>ensure checkForInterrupt is only called every 1ms.
>
>We use the forceInterruptCheck to force a checkForInterrupt call, that is
>done on finalization signaling, lowspace, become:, incremental/full GC,
>exernal semaphore signalling, plus a few others.
>
>On May 29, 2007, at 11:28 AM, J J wrote:
>
>>Hi all,
>>
>>I just read http://wiki.squeak.org/squeak/5682 that Tim (I think it was)
>>mentioned, and found the part about doing alternative scheduling with a
>>higher priority thread interesting.
>>
>>The question I had was, in the example it says the high priority process
>>can use Delay's to sleep while other processes are running, but what
>>happens when a process does IO? Doesn't that cause the process to yield?
>>
>>What I am thinking is, if I were to make a scheduler process that manages
>>all running processes, how can he find out every situation where a
>>process yields in some way? It would be ideal if there was a Delay
>>millisecondsOrUntilInterupt: type message.
>>
>>Thanks,
>>Jason
>>
>>_________________________________________________________________
>>More photos, more messages, more storageget 2GB with Windows Live
>>Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-
>>us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507
>>
>>
>
>--
>========================================================================
>===
>John M. McIntosh <[hidden email]>
>Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>========================================================================
>===
>
>
>

_________________________________________________________________
Catch suspicious messages before you open themwith Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_protection_0507

J J-6

Re: Alternative Thread Schedulers

In reply to this post by timrowledge

>From: tim Rowledge <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>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 Magazines 2007 editors choice for best Web mailaward-winning Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

J J-6

Re: Alternative Thread Schedulers

In reply to this post by timrowledge

From: tim Rowledge <[hidden email]>

>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Alternative Thread Schedulers
>Date: Tue, 29 May 2007 13:48:07 -0700
>
>Not as such, no. *IF* you implement the io in such a way that it can be
>non-blocking (see the somewhat mouldy AsynchFile class for an example)
>then you would indeed make the relevant thread/Process yield by way of
>waiting on a semaphore.

Oh sorry, missed this part in my response. Actually, this is exactly what I
*don't* want. I don't want to jump through special hoops doing IO just to
play nice with scheduling, I want it to be that way by default like in the
OS. Sounds like I may have more work cut out for me then I thought. :)

_________________________________________________________________
Catch suspicious messages before you open themwith Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_protection_0507

Andreas.Raab

Re: Alternative Thread Schedulers

In reply to this post by J J-6

J J wrote:
> 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.

Tweak contains an example for this. It's ScriptScheduler is a custom
scheduler which guarantees that each script (process) under its control
is scheduled with the semantics that I defined for it (check out the
Croquet SDK to see it in action).

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

You'd have to do something similar to Tweak's scheduler then. You can't
beat the VM into not switching processes or putting your process in
control of all the other processes. What you can do however is to
instruct *your* processes such that they adhere to your rules within
your context.

> 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'd think because of I/O speed. It would be trivial to fire off a couple
thousand processes in Squeak (I have done that). However, webservers are
often not limited by how quickly they switch between processes but
rather how effectively they can pump I/O (files) to the network (which,
if done right, doesn't require any user-level code in the middle at all).

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

I haven't looked at the code but I somewhat doubt that. It'd be trivial
to fix (see below).

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

Yes, prioritizing the quick requests is certainly a good idea for
something like a web-server. Though, a simpler version would be to run a
high priority process that simply yields every 50msecs or so to shuffle
the worker processes a little. It wouldn't be quite as effective as your
event scheduler but -having done a custom scheduler- it is *infinitely*
easier to implement ;-)

Cheers,
- Andreas

Bert Freudenberg

Re: Alternative Thread Schedulers

In reply to this post by J J-6

On May 30, 2007, at 8:21 , J J wrote:

> From: tim Rowledge <[hidden email]>
>> Reply-To: The general-purpose Squeak developers list<squeak-
>> [hidden email]>
>> To: The general-purpose Squeak developers list<squeak-
>> [hidden email]>
>> Subject: Re: Alternative Thread Schedulers
>> Date: Tue, 29 May 2007 13:48:07 -0700
>>
>> Not as such, no. *IF* you implement the io in such a way that it
>> can be non-blocking (see the somewhat mouldy AsynchFile class for
>> an example) then you would indeed make the relevant thread/
>> Process yield by way of waiting on a semaphore.
>
> Oh sorry, missed this part in my response. Actually, this is
> exactly what I *don't* want. I don't want to jump through special
> hoops doing IO just to play nice with scheduling, I want it to be
> that way by default like in the OS. Sounds like I may have more
> work cut out for me then I thought. :)

This referred to file i/o. If I am not mistaken, socket i/o actually
uses delays and semaphores a lot.

- Bert -

Göran Krampe

Re: Alternative Thread Schedulers

In reply to this post by Andreas.Raab

Hi!

> J J wrote:
>> 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.
>
> I haven't looked at the code but I somewhat doubt that. It'd be trivial
> to fix (see below).

I just looked and yes, AFAICT from a visual short inspection the forked
process to serve a new connection does indeed not get any specific prio -
it will thus use the same as the TcpService uses, which I think is by
default #userBackgroundPriority (30).

Now, I am not sure if this is a problem in practice - perhaps we already
have some higher prio process that causes these processes to shuffle
around as Andreas describes it.

regards, Göran

johnmci

Re: Alternative Thread Schedulers

In reply to this post by J J-6

On May 29, 2007, at 11:08 PM, J J wrote:

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

wakeHigestPriority looks at the list of runnable processes which is a
sorted list by priority. Each element in the list is actually a
linked list
of processes that are able to run at that priority level. There is
an idle loop process at the bottom which when run means there is no
work to be done by the VM.
The idle task invokes a VM primitive to make the VM sleep. In the far
past this was a set amount of milliseconds, years ago it was changed
to sleep upto the next
Delay timing point, and/or wake if the operating system received an I/
O interrupt of some form assuming the operating system and sleep call
supports that.

What's important is what is the next runnable process. That can be
adjusted in the ProcessScheduler Smalltalk class by suspending
processes you don't want to run yet, or adjusting priorities to sort
the processes into something different.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Bryce Kampjes

Re: Alternative Thread Schedulers

In reply to this post by J J-6

J J writes:
> 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.

At some point it would be nice to have some scheduling support for
Exupery. When running as a background compiler Exupery runs in a
separate, Squeak, process. Ideally, Exupery should be allowed all the
time when nothing else is going on but not starved completely if the
process is busy so the system can still optimize itself under load.

Exupery shouldn't be able to starve other processes or get starved
itself.

Bryce

J J-6

Re: Alternative Thread Schedulers

In reply to this post by Andreas.Raab

>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Alternative Thread Schedulers
>Date: Tue, 29 May 2007 23:41:33 -0700
>
>Tweak contains an example for this. It's ScriptScheduler is a custom
>scheduler which guarantees that each script (process) under its control is
>scheduled with the semantics that I defined for it (check out the Croquet
>SDK to see it in action).

Ok, I will go check that out then.

>I'd think because of I/O speed. It would be trivial to fire off a couple
>thousand processes in Squeak (I have done that). However, webservers are
>often not limited by how quickly they switch between processes but rather
>how effectively they can pump I/O (files) to the network (which, if done
>right, doesn't require any user-level code in the middle at all).

Yea, I realize the majority of the time isn't spend scheduling, but I do
think such an approach could make the system feel more snappy in cases
without the user having to do anything extra.

As far as the IO, maybe we could add a primitive for that system call
lighttp (the fastest page serving web server on the planet afaik) uses to
write files directly to the network.

>Yes, prioritizing the quick requests is certainly a good idea for something
>like a web-server. Though, a simpler version would be to run a high
>priority process that simply yields every 50msecs or so to shuffle the
>worker processes a little. It wouldn't be quite as effective as your event
>scheduler but -having done a custom scheduler- it is *infinitely* easier to
>implement ;-)
>
>Cheers,
> - Andreas

Well I appreciate the info. If I do this it would be an experiment type
thing for some ideas I have, so it's ok if it's hard to do and just gets
thrown away after I do my tests. Though the harder it is to do the further
down the "todo list" it goes. :)

_________________________________________________________________
More photos, more messages, more storageget 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

J J-6

Re: Alternative Thread Schedulers

In reply to this post by johnmci

>From: John M McIntosh <[hidden email]>
>Reply-To: [hidden email],The general-purpose Squeak
>developers list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Alternative Thread Schedulers
>Date: Wed, 30 May 2007 10:02:27 -0700
>
>
>On May 29, 2007, at 11:08 PM, J J wrote:
>
>What's important is what is the next runnable process. That can be
>adjusted in the ProcessScheduler Smalltalk class by suspending processes
>you don't want to run yet, or adjusting priorities to sort the processes
>into something different.

That is a great idea! I can just suspend every process except the one I
want to be current, and the scheduler (I will probably have to have my own
lists for the processes anyway). Now if my scheduler process calls
#waitMilliseconds: 250 and the VM decides the current process needs to
sleep, will he wake up my processor object even though the 250 milliseconds
are not over, or he would go to the idle process at that point?

I guess it doesn't matter, I would just have to have a timer interupt class
that did the #waitMilliseconds and the actual Scheduler class at a low
priority to take control when the VM wants to switch to a new process.
Everything else (except real-time processes) would be suspended until I
explicitly resume them.

_________________________________________________________________
More photos, more messages, more storageget 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

J J-6

Re: Alternative Thread Schedulers

In reply to this post by Bryce Kampjes

>From: <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Alternative Thread Schedulers
>Date: Wed, 30 May 2007 21:20:50 +0100
>
>At some point it would be nice to have some scheduling support for
>Exupery. When running as a background compiler Exupery runs in a
>separate, Squeak, process. Ideally, Exupery should be allowed all the
>time when nothing else is going on but not starved completely if the
>process is busy so the system can still optimize itself under load.
>
>Exupery shouldn't be able to starve other processes or get starved
>itself.
>
>Bryce

I think the scheduler I described would do this. Theoretically it would be
possible for the high priority processes to keep using the CPU so that
Exupery never gets to run, but in practice I think the processes will either
stay off the CPU (which is why they are high priority) or if they do use the
processor too much they get demoted until they are at the same priority of
Exupery, at which point he can run.

_________________________________________________________________
Like the way Microsoft Office Outlook works? Youll love Windows Live
Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_outlook_0507

timrowledge

Re: Alternative Thread Schedulers

In reply to this post by J J-6

On 30-May-07, at 2:52 PM, J J wrote:

>
> That is a great idea! I can just suspend every process except the
> one I want to be current, and the scheduler (
Last time I checked - about thirty seconds ago using the
ProcessBrowser - there isn't a scheduler process. I suspect you need
to do a fair bit more reading to find what is in the system already.
It seems to me you're getting a bit confused about how the current
scheduling works.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- VENI, VIDI, VICE - I came, I saw, I partied.

johnmci

Re: Alternative Thread Schedulers

Right Tim, he would have to add one, need *something* to suspending
things and fiddling with the list of runnable processes.

On May 30, 2007, at 3:24 PM, tim Rowledge wrote:

>
> On 30-May-07, at 2:52 PM, J J wrote:
>
>>
>> That is a great idea! I can just suspend every process except the
>> one I want to be current, and the scheduler (
> Last time I checked - about thirty seconds ago using the
> ProcessBrowser - there isn't a scheduler process. I suspect you
> need to do a fair bit more reading to find what is in the system
> already. It seems to me you're getting a bit confused about how the
> current scheduling works.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Fractured Idiom:- VENI, VIDI, VICE - I came, I saw, I partied.
>
>
>

Lex Spoon-3

Re: Alternative Thread Schedulers

John M McIntosh <[hidden email]> writes:
> Right Tim, he would have to add one, need *something* to suspending
> things and fiddling with the list of runnable processes.

Yes, that should be enough. This strategy applies to all kinds of
thread systems, not just Squeak's, and allows you to bootstrap a new
scheduler on top of an existing one.

Some general thoughts about this scheme:

1. Make the scheduler high-priority, so that it reliably gets control
whenever it wants to.

2. Possible make your own "idle" process, one notch above the current
idle process, so that you can detect a lack of activity. This
process can wake up the high-priority one, if you want, by
signalling a semaphore that the high-priority one notices.

3. Consider limiting your schedule to managing a list of threads that
are registered with it, as opposed to literally managing all
threads in the system. This way it plays a little nicer with
anything else that might be running.

Oh, and the obvious:

4. Save often, and make lots of backups. Screwing up thread
scheduling can really ruin an image!

Lex

johnmci

Re: Alternative Thread Schedulers

On Jun 1, 2007, at 7:54 AM, Lex Spoon wrote:

> 2. Possible make your own "idle" process, one notch above the current
> idle process, so that you can detect a lack of activity. This
> process can wake up the high-priority one, if you want, by
> signalling a semaphore that the high-priority one notices.

Ah, this is good. Don't fiddle with the system's idle process. Many
years ago I tried that, we even pushed the
change out, followed a few hours later by an emergency fix. The
intent was to change the idle logic from sleeping
a default of 10 ms (or something) to sleeping up to the next wakeup
Delay timing point.

We discovered (Scott did I think) that the code in Smalltalk which
went off to find out that information *could* if
the objects aligned right then wait on the Delay semeaphore. Which
then result in the VM terminating because
there was no runnable process since the idle process was stalled
waiting on the Delay semaphore.

A few years after this we did put back in logic in the VM idle
primitive to get the next wakeup time because the
VM was handed that information as part of the Delay logic. Thus it
can sleep upto the next wakeup tick, baring
interrupts from the operating system which terminate the operating
system's sleep api logic early. That improved
Delay accuracy and reduced CPU needs for idle system.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===