On 21/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 10/21/07, Igor Stasenko <siguctua at gmail.com> wrote:
> >
> > I don't think this have a sense. Classes should be treated as regular
> > objects (everything is an object - remember?), and due to that fact
> > you can't make preferences over different kind of objects.
>
> Ah, but they are the same, I'm not making a difference, I'm making an
> optimization and not getting caught. ;)
>
> > Class
> > objects and instance objects are the same: objects holding a mutable
> > state.
>
> Fine, you can have mutable state.  But only within your own process.
> If you change it no other process will see it.
>
> > A method dictionary is a mutable state of class, so changing it should
> > affect all objects of given class immediately.
>
> This is a special case in my envisioned system, just as it's a special case now.
>
> > And btw, i starting doubt about 'no sharing at all' paradigm. Just in
> > one of the links you given about Erlang, one of the readers commented:
> > (http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html)
>
> Ok, so someone presented a counter-point about a meaningless analogy,
> and that disproves the power of message passing?
>
> You can doubt it if you want.  You can work incredibly hard for the
> next 5, 10 years or however long it takes and add native thread shared
> state concurrency to Squeak.  But Erlang will continue to gain market
> share.  Dinosaurs like Java, with their old shared-state model will
> get less and less relevant as concurrent software gets the complexity
> explosion that web software is going through now.  And if your fast
> you will make it just in time to charge into the party as the last
> light goes out.
>
> > There an obvious evidence of a system which performs in parallel by
> > having a single shared state - human brain. Do we experience heavy
> > 'locking' or 'concurrency' problems?
> > Personally, I'm not :) And if so, then why sharing state should be
> > considered evil?
>
> For the same reason manual memory management is in most cases:  It's
> too hard to get right, it's too hard to reason about, it's impossible
> to compose with other software made independently.
>
> Now of course we can get back into the watershed of beating ourselves
> for being "bad programmers" but after so many failed projects, and
> success itself meaning simply having a small enough critical bugs to
> be usable, maybe we should admit we're trying to put the shoe on
> backwards.
>
> > Also, in fact, you can't eliminate using shared state at all.
>
> I don't think that's been proven at all.  In fact there have been
> OS'es to do exactly that.
>
> > There can be only a ways how to delegate shared state management to
> > outer context (such as OS, or VM e.t.c).
>
> That it doesn't have to be shared state.  Does Linux have shared
> state?  I don't recall ever having to lock a mutex before reading a
> disk, or allocating memory or anything.  Of course Linux does have
> shared resources internally, but if you broke it up into smaller
> "Kernels" that each had a the same interface between each other then
> perhaps this could be eliminated.
>
> > A 'fine-grained' locking is nothing more than manual controlling of
> > shared state made by developer.
>
> Exactly, and manual memory management is nothing more then manual
> controlling of memory made by the developer.
>
> > Try implement Erlang (or any other system which uses parallel
> > computations and having a shared state) without locks and semaphores.
>
> That depends on the OS and CPU, not the problem domain.
>
> > So, tell me, what the difference between
> > manually controlling it, or 'magically', like Erlang does?
>
> Seriously?  Well lets see:  (1) lines of code needed to accomplish a
> given task, (2) literally man *years* of work time, (3) stability of
> finished product (or perhaps you know of a Java/C++/whatever system
> that is in heavy use and achieves 9 9's of reliability?), (4)
> difficulty of solving bug that do appear due to concurrency, (5) the
> ability to solve concurrency issues at *design time* instead of
> *implementation time* (probably the most important of all of them),
> ....
>
> > A proposed a message passing between different OS processes(squeak
> > images) is nothing more than letting OS deal with shared state
> > problems (locks/queing e.t.c).. naively thinking that we are get rid
> > of shared state concurrency. Are we really do?
>
> Please reread what you wrote here because.... What you basically said
> is "doing X is nothing more then letting the OS and/or system deal
> with the complexity for us and naively thinking it just goes away".
> Is this not the exact reason we are using Smalltalk instead of C++, C
> or assembler?
>
Hehe, then all we need is to implement ST with Erlang and we are fine. Yes? :)
If you noticed, i'm not arguing about is it possible to make ST VM
ready for multi-core.
I'm really pointing on, how efficient it can be (depends on proposed
solutions) and what we can do to make good VM competing by speed with
other language platforms.
If we not taking speed into account, then there's nothing to talk about.

And don't tell me that trying to make ST to run as fast as can is
pointless...  Such thoughts are only for people, who taking a car and
drive to wall-mart to buy a glass of water, located in 20 feets from
their house.

For same reasons as you don't want use C++/C/assembler for your
projects i don't want them too. But at same time, i don't like being
sitting and waiting, while other parts of system (OS/Hardware) become
so advanced to make my code run smoothly. If i don't like how it runs,
i trying to fix that instead of waiting until someone else will fix
it.

As side note, i don't want to make one ST Process === single native
thread. Such solution is really 'obsolete' and lead to nowhere. I'm
talking about VM which conserves all CPU(s) power while managing
execution/GC seamlessly to language. The in-language Processes and
semaphores must not have any relation to native threads or number of
cores. It's just a language level abstraction, nothing more. In that
case, i can't see how 'manual fine grained locking' can do any harm.
If you need to synchronize access to some object you simply can't
avoid that - at any level of abstraction (being in Erlang or OS, or
assembler).


-- 
Best regards,
Igor Stasenko AKA sig.