Alternative Thread Schedulers

J J azreal1977 at hotmail.com
Wed May 30 05:17:43 UTC 2007


>From: John M McIntosh <johnmci at smalltalkconsulting.com>
>Reply-To: johnmci at smalltalkconsulting.com,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 14:02:16 -0700
>
>I'm sure there was mail earlier asking about when a process switch  
>happens.

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 storage—get 2GB with Windows Live  
>>Hotmail. http://imagine-windowslive.com/hotmail/?locale=en- 
>>us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507
>>
>>
>
>--
>======================================================================== 
>===
>John M. McIntosh <johnmci at smalltalkconsulting.com>
>Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>======================================================================== 
>===
>
>
>

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




More information about the Squeak-dev mailing list