On 10/25/07, Peter William Lount peter@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.