Multithreading

John M McIntosh johnmci at smalltalkconsulting.com
Tue Mar 29 07:10:52 UTC 2005


On Mar 28, 2005, at 9:28 PM, Tim Rowledge wrote:

> Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
>
>>
>>
>> I thought from earlier remarks (not by you) that even a lower priority
>> process could block a higher priority process, if the former did not
>> yield control.
> Higher priority processes that are in a runnablestate (ie not held back
> by a semaphore etc) will take control away from any lower priority
> process just as soon as they can. As John said, that opportunity comes
> with every message send and backwards branch bytecode, which is quite
> frequently. However, if a low priority process calls a very long
> running prim (right now any DNS related activity counts as a
> geologically long prim on my setup; damn telus DNS...) then you can be
> held up for a while. VW has some mechanism for combating this by ...
> well some means or other involving native threads.

Well I spent a few minutes trying to make a method that locks things  
up, but that is difficult
test
	| a |
	1 to: 100000000 do: [:i | a ].

involves a backwards jump

test
	self test

involves a method send. I think any reasonable smalltalk method would  
involve a message send or backwards jump at some point. As mentioned by  
Tim a long running prim does cause you problems, and  as noted in VW  
they have a pthread (or similar) based solution to solve the impact of   
long running blocking prim calls. A week with the plugin
logic in Squeak would give you a similar solution.
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Squeak-dev mailing list