On 30/10/2007, nicolas cellier ncellier@ifrance.com wrote:
Igor Stasenko a écrit :
I'd like to hear more critics about such model :) If it proves to be viable and much or less easily doable (comparing to other models) then i could start working on it :)
Hi Igor, I like your approach. Main problem I see is that a lot of methods in current image are not multi-process safe! Imagine one SortedCollection, one Process iterates on it, another add to it. Even now, with a single threaded image, you have to care! (see http://bugs.squeak.org/view.php?id=6030).
Exactly the OrderedCollection counter argument you served to Andreas! Except Andreas knows he has to carefully choose shared states, and also has explicit futures and promises he is using sparingly, and can identify easily.
Your users will need atomic operations. Thus you have to introduce another state attached to receiver object telling that you can read concurrently, but not put a write lock on it. (in fact, you have 3 states, read-locked <-> free <-> write-locked)
From pragmatic POV, prepare to put atomic blocks everywhere before having something usable! (maybe an <#atomic> pragma to be lighter). You cannot simply state "that's a programmer problem, I provide the framework". Bugs might occur from time to time, very hard to debug ones! And your framework won't help much.
Beside, your users will have to deal with deadlock cases too... We'd better start thinking of automatic deadlock detection...
Hi Nicolas. I stated previously that my approach not dealing with mutithreading problems at language side. There is no ways how to deal with them at low level (such as VM). And if you read in previous discussions, they proven that there can't be a single generic solution for all problems which raising when we go in parallel world. Some solutions work best for ones, but can be too ineffective for others.
That's why i proposed to not bind VM parallelism with language parallelism. We can't have a multiple ways in having concurrency in single VM implementation simply because of complexity of such system will be paramount. So we must choose a single solution (be it good or bad :) ). In same way as currently you can have multiple ST processes running in parallel, same you can do in future VM. The rest is on your own hands. You are free to use mutexes/futures or anything you like to deal with concurrency. A new VM simply should utilize CPU power better, so that if you have more and more cores from year to year, your code runs faster and faster. Of course this happens only, if you using algorithms which can divide your task into number of parallel sub-tasks.
Nicolas