Concurrent Futures

Igor Stasenko siguctua at gmail.com
Mon Oct 29 23:56:10 UTC 2007


On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Monday, October 29, 2007 3:52 PM
> Subject: Re: Concurrent Futures
>
>
> > On 30/10/2007, Giovanni Corriga <giovanni at corriga.net> wrote:
> >> Il giorno lun, 29/10/2007 alle 13.34 -0800, Andreas Raab ha scritto:
> >>
> >> > Not "all messages sends". Only messages between concurrent entities
> >> > (islands). This is the main difference to the all-out actors model
> >> > (where each object is its own unit of concurrency) and has the
> >> > advantage
> >> > that you can reuse all of todays single-threaded code.
> >>
> >> Just out of curiosity, how much work do you think it would be necessary
> >> to port the Islands system to the standard Squeak image?
> >>
> >>         Giovanni
> >>
> > This is what i mean. There is a BIG difference between concurrency
> > (parallel execution with shared memory) and distributed computing.
> > An 'islands' is fitting good for distributed computing, but does they
> > fit for concurrent parallel execution? I doubt.
>
> Igor, where would you place concurrency with disjoint memories?
>
> Would assigning objects to specific processes, within a shared memory, such
> that only those processes could mutate that object and the processes were
> non-interruptable and non-waitable, would that be sufficient to make it
> disjoint?  Imagine that every object reference (header) was assigned to a
> specific Vat, and only processes within that Vat could interact with that
> object.  All msg sends to that object, from other Vats, would be eventually
> scheduled with that object's Vat.
>

Simply because its not scales well. Consider a 1000 and 1 Vats ( 1000
and 1 tales comes in mind :).
A 1000 Vats sending a message to the same object, which is scheduled
in single Vat. So, there will be a HUGE difference in time between
first sender and last sender when they will receive an answer.
Yes, for some messages its the only answer, but for other messages,
like simply asking a state (like accessor), there's no need in
synchronization, because there's no changes in state and no real need
in scheduling.

Concept you give is really close to one , which i have in mind. Except
the example above, which seems will be always a bottleneck.

> Rob

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list