On 23/10/2007, Peter William Lount peter@smalltalk.org wrote:
[ your message was here ]
Peter William Lount Peter@smalltalk.org
A BIG +1 to your point. You expressed most things which i had in mind (i'm not native English speaker, so sometimes its hard to say what i have in mind).
Absolutely, there is no magical cure for concurrency. And hoping that we can deal with it by using __insert tool__ is an illusion.
And what is more frustrating (unfortunately), that a concurrency can be solved only when we come to problem from both sides: VM and language. By changing VM and not touching a bit in ST codebase we will have a crappy solution. By changing ST codebase, but using old one-threaded VM we have also crappy solution - while its very useful for generic distributed computing its too ineffective for computationally heavy problems (for example - raytracing). While you can do things in parallel, but in the end you must gather results into same memory space. Its good when your problem domain can be simply splitted onto smaller parts, which can be computed in parallel and overhead of objects serialization is too low comparing to time of computing partial results. But as Peter said in general case we may expect that overhead will be too high for some tasks, and some tasks can't be parallelised at all making single OS process working, while others simply hanging in memory eating space and consuming CPU resources by computing nothing.
Also, by spawning parallel OS processes we hand over many aspects of our parallel processing control to OS and losing many elegant and simple solutions. For example, why i have to lose simple 'send and receive' and be it replaced by 'send and pray' paradigm?
And don't take me wrong: i'm a big fan of spoon and Croquet islands, still these solutions hardly can be considered as generic in perspective of Multi-Core. Lets make it clear: a Multi-Core is _NOT_ distributed computing. Yet they have many in common, but to use them most effectively we need different approaches.