>From: karl <karl.ramberg at comhem.se>
>Reply-To: 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: election details *PLEASE READ*
>Date: Thu, 22 Feb 2007 22:44:07 +0100
>
>>I think we should try to take things from other languages that make sense 
>>for smalltalk, but I don't think there will be a time when one language 
>>(even smalltalk!) will be perfect for every task.  We will still need at 
>>least Haskell. :)
>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 ?

Afaik there are 3 ways of handling true concurrent execution (i.e. not green 
threads):

1) Fine-grained locking/shared thread state:

The old way of running heavy weight threads, sharing memory across threads 
and using some kind of locking to protect against race conditions.

Positive:  Hrm, well I guess there is the most support for this, since it is 
probably the most common.  If you don't use any locking but only read the 
data shared this is very fast approach.

Negative: It simply doesn't scale well.  It also doesn't compose well.  You 
can't simply put two independently created pieces of code together that use 
locking and expect it to work.  Stated another way, fine-grained locking is 
the manual memory management of concurrency methodologies [1].  If any part 
of your code is doing fine-grain locking, you can never "just use it" 
somewhere else.  You have to dig deep down in every method to make sure you 
aren't going to cause a deadlock.

This one would probably be very hard to add to Squeak based on what John 
said.

2) Shared state, transactional memory:

Think relational database.  You stick a series of code in an "atomic" block 
and the system does what it has to to make it appear as the memory changes 
occurred atomically.

Positive:  This approach affords some composability.  You still should know 
if the methods your calling are going to operate on memory, but in the case 
that you put two pieces of code together that you know will, you can just 
slap an atomic block around them and it works.  The system can also ensure 
that nested atomic blocks work as expected to further aid composability.  
This approach can often require very few changes to existing code to make it 
thread safe.  And finally, you can still have all (most?) of the benefits of 
thread-shared memory without having to give up so much abstraction (i.e. 
work at such a low level).

Negative:  To continue the above analogy, I consider this one the "reference 
counted memory management" of options.  That is, it works as expected, but 
can end up taking more resources and time in the end.  My concern with this 
approach is that it still does need some knowledge of what the code you are 
calling does at a lower level.  And most people aren't going to want to 
worry about it so they will just stick "atomic" everywhere.  That probably 
wont hurt anything, but it forces the system to keep track of a lot more 
things then it should, and this bookkeeping is not free.

This one would also require some VM (probably very big) changes to support 
and could be tough to get right.

3) Share nothing message passing:

Basically, no threads, only independent processes that send messages between 
each other to get work done.

Positive:  This approach also allows a high level of composability.  If you 
get new requirements, you typically add new processes to deal with them.  
And at last, you don't have to think about what the other "guy" is going to 
do.  A system designed in this manner is very scalable; in Erlang for 
example, a message send doesn't have to worry if it is sending to a local 
process or a totally different computer.  A message send is a message send.  
There is no locking at all in this system, so no process is sleeping waiting 
for some other process to get finished with a resource it wants (low level 
concerns).  Instead a process will block waiting for another process to give 
him work (high level concerns).

Negative:  This requires a new way of architecting in the places that use 
it.  What we are used to is; call a function and wait for an answer.  An 
approach like this works best if your message senders never care about 
answers.  The "main loop" sends out work, the consumers consume it and 
generate output that they send to other consumers (i.e. not the main loop).  
In some cases, what we would normally do in a method is done in a whole 
other process.  Code that uses this in smalltalk will also have to take 
care, as we *do* have state that could leak to local processes.  We would 
either have to make a big change how #fork and co. work today to ensure no 
information can be shared, or we would have to take care in our coding that 
we don't make changes to data that might be shared.

I think this one would be, by far, the easiest to add to Squeak (unless we 
have to change #fork and co, of course).  I think the same code that writes 
out objects to a file could be used to serialize them over the network.  The 
system/package/whatever can check the recipient of a message send to decide 
if it is a local call that doesn't need to be serialized or not.

[1] The big win usually cited for GC's is something to the effect of "well, 
people forget to clean up after themselves and this frees up their time by 
not making them".  But really, the big win was composability.  In any 
GC-less system, it is always a nightmare of who has responsibility for 
deleting what, when.  You can't just use a new vendor API, you have to know 
if it cleans up after itself, do I have to do it, is there some API I call?  
With a GC you just forget about it, use the API and everything works.

_________________________________________________________________
Win a Zune™—make MSN® your homepage for your chance to win! 
http://homepage.msn.com/zune?icid=hmetagline