On 30/10/2007, Rob Withers reefedjib@yahoo.com wrote:
----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, October 29, 2007 3:52 PM Subject: Re: Concurrent Futures
On 30/10/2007, Giovanni Corriga giovanni@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