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
|