On 10/30/07, Igor Stasenko <siguctua at 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.