Multy-core CPUs

Jason Johnson jason.johnson.081 at gmail.com
Thu Oct 25 16:40:10 UTC 2007


On 10/25/07, Peter William Lount <peter at smalltalk.org> wrote:
> Hi,
>
> Slicing up the data objects and shipping them in one deep copied parcel
> from one Smalltalk image to another isn't a general solution. It may be
> a solution for some problems that can be simplified but it will NOT work
> for the majority of problems. In fact I'd find a "deep copy and split up
> the data objects only solution" quite useless for most of the parallel
> problems that I'm working on solving.

Ok, you just made a jump there from "majority of problems" to "most of
the problems that *I'm* working on".  It works just fine for the
problems I'm interested in at the moment, and obviously for most of
the problems businesses, etc. are using Erlang for.

So what are these "majority of problems" you're talking about and who
is solving them now?

> In the general large scale case that I gave as an example (in an earlier
> email) the one million data objects could be retrieved or accessed by
> any of the 10,000 processes used in the example. While shipping them all
> in a deep copied parcel in one message is possible it's not always the
> wisest move.

And why would you do that?  No paradigm can remove the responsibility
to think from the programmer.  As I've said I don't know how many
times, the point of this is simply to move this to design where it
belongs instead of implementation where it is now.

Sharing memory is breaking encapsulation.


> A key characteristic of the general problems
> is that the data objects can and must be accessible from ANY of the
> forked off processes with ANY of them being able to alter the objects at
> any point in time with those changes being propagated back to the
> central node (assuming there is just one central node) when a commit
> occurs and then updating the other forked off processes that have an
> interest in seeing updates to objects in mid transaction. Some of these
> changes will of course nullify the work of some of these processes
> requiring them to abort and possibly start over with the newest changes.
> Too many interacting changes between the processes will of course cause
> too many aborts and retry (assuming that's the chosen mechanism for
> dealing with overlapping changes that are mutually exclusive resulting
> in inconsistency to the data objects).

You lost me again.  You seem to come up with a problem *and the way
you want it solved* and then complain that a message passing paradigm
can't solve it.  What does that prove?

> Solving for 90%
> of the cases will thus require much more than what is being proposed by
> the simplify concurrency at the loss of capability proponents.

Your 90% is different then mine then.  In fact, I can't think of any
concurrency problems I wish to resolve that this *wont* handle.

> What are needed are solutions that cover various chunks of the solution
> space and a way of selecting the correct solution mechanisms either
> manually or automatically (preferred if viable). Then the "deep copy and
> split up the data objects only solution" may do it's part as a piece in
> a wider matrix of solutions. To dispense with the tools we need to solve
> the general problems is folly IMHV (In My Humble View).

We already have.  Or is Squeak/most Smalltalks folly?  There are
certain classes of memory management that don't work well with a GC,
but would with manual memory management.  Is it a mistake to deny it's
use at the language level?

> An excellent book for learning the ins and outs of concurrency control -
> and most importantly the common mistakes - is the free PDF book, "The
> Little Book of Semaphores",  by Allen B. Downey and his students:
> http://www.greenteapress.com/semaphores/downey05semaphores.pdf. Enjoy
> the full power of parallel programming.

For me that's just old-think.  Solutions to incredibly complex
problems we never would have had if we simply avoided violating
encapsulation.



More information about the Squeak-dev mailing list