election details *PLEASE READ*

John M McIntosh johnmci at smalltalkconsulting.com
Fri Feb 23 03:34:07 UTC 2007


On Feb 22, 2007, at 3:21 PM, <bryce at kampjes.demon.co.uk> wrote:

> karl writes:
>
>> Another issue that will come up in the near future is multi core
>> processors. What must be done with Squeak to utilize all the  
>> processors
>> and what are the benefits and drawback of the  different approaches ?
>> What can  the board do to help in this effort ?
>
> That said, the biggest difficulty with moving the VM to multithreaded
> execution is the garbage collector and write barrier.

In thinking about that in the past there are some interesting places  
in the smalltalk code where
we don't consider a VM could be executing the same logic twice when  
referring to a class variable
and the like. Right now this code is "safe" because the VM actually  
only switches processes at
known times  so we do a, b, and c and it's "safe" because a process  
switch doesn't happen and
since there isn't multiple concurrent threads we don't have an  
issue.  Process switches only happen
at certain times, mmm and the list is where?

But if you ran multiple threads, that same execution path could fail  
if one process does a and b
then the other attempts a but c on the other thread was required to  
finish and fix up 'a'.

In general the Smalltalk code is not truly fine grained thread safe.  
A fun task I'm sure...

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===





More information about the Squeak-dev mailing list