On 10/30/07, Igor Stasenko siguctua@gmail.com wrote:
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.
Are you some how under the impression that a shared state solution would actually scale *better*? Think about that. In the E solution, those 1000 vats basically post an event to that same object in the single vat.... then they go on about their business.
Shared state on the other hand..... if there is *any* code *anywhere* in the image that can modify this object then *all* access to the object has to be synchronized [1]. This means that while the E code is chugging away doing all kinds of things, your synchronized, native thread code has 1000 processes all sitting in a queue waiting their turn to get the lock. Of course you could spawn a new thread for every blocking access so you don't have to wait, but then you'll just be where E already is with a much higher resource usage.
[1] The exception here would be if the object is so simple that you can *prove* that any writes to it are atomic. But you better put a huge flashing comment with it saying that if anyone adds *anything* they will have to add synchronization in a *lot* of places, and will possibly fundamentally alter the run time performance of the program.