On 18/03/2009, at 10:46 PM, Igor Stasenko wrote:

> I hear the magic word 'concurrency' .. :)
> With green threading model we have a kind of concurrency on a  
> language level..
> except that its not scaling on to multiple native threads.

The Erlang/Scala/Clojure concurrency models are applicable to a green  
threads model. Concurrency is difficult even with green threads.

> There were a lot of discussion around native threading support and
> everyone agrees that less sharing means less problems.

Which is what such concurrency models provide. I suggest gaining some  
familiarity with Erlang/Scala/Clojure to protect against Smalltalk- 
insularity.

> From this point, running separate object memory per native thread seem
> most perspective way.

That ties you to only doing large grained concurrency. What if I want  
thousands of threads, automatically distributed over the available  
hardware? Are you assuming that concurrency is limited to the number  
of running images, and each image is strictly single threaded?  
Concurrency is useful at many different levels of granularity. Using  
multiple images requires you to use one method for dealing with per- 
image concurrency (and currently those mechanisms aren't great) and  
another when considering multiple threads. And what about the tools to  
make debugging, profiling, deployment, management etc work over these  
multi-image systems? That might be more work than just biting the  
bullet and providing scalable concurrency within the image.

> Running single object memory on multiple native threads opens a can of
> worms. And the complexity of VM implementation will be overwhelming.

Not neccessarily. There may well be legacy issues related to specific  
VMs and images, but the problem itself is not overwhelming. If it were  
you wouldn't have the JVM or CLR.

This argument is exactly what I meant when I wrote:

> If this were the "good old days"(TM) I'm sure someone would be  
> working on decent concurrency support for Smalltalk. Using multiple  
> images is one approach, but not one that I like - it seems (IMHO) to  
> be a reaction to the lack of resources to do something better.

I would prefer to tackle this problem and do something worthy of  
Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the  
multi-image model is actually a good and principled decision - but  
it's not, it's surrender.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

In anything at all, perfection is finally attained not when there is  
no longer anything to add, but when there is no longer anything to  
take away.
   -- Antoine de Saint-Exupery



_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to