On 30/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
>
> >> > 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.
>
> Ok, so we have coded a bottleneck situation.  It's not a surprise, since we
> have a 1000 objects asking for it's services.  It's time for a refactor and
> remove that bottleneck with some service duplication and load balancing.
> Using promises or futures doesn't remove bad code, just limits the kinds of
> bad code you can have.  This would also be a problem in a distributed
> application that was sending 1000 service requests to a single object.
>
> Regarding accessing some state for a read.  If 2 Vats or Islands are on the
> same processor with shared memory between them and Vat A tries to access the
> state of an object owned by Vat B, as long as there is no relocation
> occurring, we should be able to optimize access to this state with a direct
> memory read operation.  Of course, in Smalltalk we access state owned by an
> object by sending that object a read accessor msg, and I don't see how we
> could determine that a given msg sent was there just for a memory read and
> do the optimization.  It wouldn't surpise me if Exupery might know such
> things.
>
> I'd like to hear some description if the concept you have in mind, if you
> have the time.  What are you thinking about in this arena?
>
Well, in my concept i don't have a vats. A computing resources(native
threads) managed by VM and not visible at language level. So, a VM
parallelism is not a language parallelism.
You can't predict what native thread will serve concrete message for
concrete object, thus a load is distributed evenly.
This haves own limitations, but mostly when you interacting with
external libraries through primitives - some of the libraries can not
work (or can work differently) when you accessing them from different
native threads.
Some of the libraries designed with no multithreading in mind, so
using them concurrently may cause a system crash.
But i don't think that i'm alone with this problem. We need to find
some good ways how to control that all calls to some external library
must be invoked only from a single thread of execution, while for
other libraries its ok to call them from anywhere.

> > --
> > Best regards,
> > Igor Stasenko AKA sig.
>
> Cheers,
> Rob
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.