Concurrent Futures

Igor Stasenko siguctua at gmail.com
Tue Oct 30 22:07:53 UTC 2007


On 30/10/2007, nicolas cellier <ncellier at 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

-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Squeak-dev mailing list