On 30/10/2007, Rob Withers reefedjib@yahoo.com wrote:
----- Original Message ----- From: "Igor Stasenko" siguctua@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