Multy-core CPUs
Peter William Lount
peter at smalltalk.org
Thu Oct 25 18:31:45 UTC 2007
Hi,
Jason Johnson wrote:
> 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?
>
You're splitting hairs with my use of English. The vast majority of
concurrency problems won't fit well with the process-based model of
concurrency (of Erlang and other systems).
Process-based model of concurrency won't solve ALL the problems.
Consider that there are an infinite number of concurrency problems.
You're telling me that the solution you are proposing solves them all?
Sure if you have a set of problems that you are solving that fit
perfectly with the process-based model of concurrency - as used in
Erlang - then excellent use that approach to solve your problems. Go for it.
However, please don't force your "process-based ONLY model of
concurrency" onto Smalltalk since there are those of us out here with
other real world problems that the process-based model of concurrency
won't solve easily or at all. This also applies for the deep coping of
objects as an only solution - it just works for a tiny subset of
problems. Please don't force ill conceived deep copying solutions upon
us as the ONLY solution.
One solution won't fit all. That's the point of a programming language -
to be general purpose enough to enable programmers or users to solve as
wide a range of problems as possible.
It sounds like you need to put your code into a library of objects that
are optional rather than forcing them into the virtual machine.
>> 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.
>
No, sharing memory does not necessarily break encapsulation. Many things
break encapsulation for sure. Blocks for one (see Alan Kay's comments on
this).
It's how you look at it. If many processes are accessing an object via
the objects methods then encapsulation is not broken since the object is
in control of who can see what and when. It doesn't matter how many
processes see the object if the object is in control of what is
happening to it. That is a current capability of Smalltalk.
>> 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?
>
I apologize if my writing wasn't clear.
I provide an example and one way (of many ways) to solve it. Yes. That's
being responsible from my perspective since I know the a solution that
will work I'm not going to hide it as some sort of covert test.
Obviously the message passing paradigm of Smalltalk can solve the
problem since that's what I've presented. What's not clear is how the
"process-based model of concurrency" - of Erlang - can solve every
concurrency problem out there. What's not clear is how Erlang would
solve the example I put forward without changing it into a slice and
dice of the original one million objects.
The point or "what does it prove" is that no one concurrency solution
will solve all the problems. I provided an example to show that and to
show the kind of nasty problem that other concurrency problems can solve.
See the "Little Book of Semaphores" that I linked to for many other
solutions to concurrency problems.
>
>> 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.
>
As I said in another recent email today your set of problems is of a
nature that can be solved that way. That's great. However, please don't
force your approach unto us all since it won't work for all of us.
Please put your solution into a library so that those who wish to use it
can do so if they so choose. Thanks.
>
>> 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.
How so?
> 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?
>
Sure Smalltalk has limits to what it can do. That is very important to
recognize it's limits.
However, within the current limits of what Smalltalk can do is working
powerfully with concurrency (albeit in a single native thread for most
but not all implementations of Smalltalk). To reduce this current
capability to solve just a subset of concurrency problems is what I'm
calling folly.
If you can provide a proof that your proposed process-based model of
concurrency methodology can solve all the concurrency problems that can
currently be solved by Smalltalk then you'll have convinced me (and
likely others). So far I'm still not even clear what you are proposing.
I work quite hard to implement more power and capability for Smalltalk
not take it away. Altering the Smalltalk language - or even one version
of it, Squeak - in such a way as to make it less powerful by removing
concurrency control capabilities isn't going to fly with me and a large
number of users of Squeak.
If you wish to do that then you'll likely need to be very creative and
put your concurrency solution into an optional class library somehow.
That will fly. Or fork a new version off of Squeak. That would also fly
with many or almost all I suspect.
In fact there are many small versions of Smalltalk such as Little
Smalltalk or Susie Smalltalk or ... that are quite limited (actually
almost all Smalltalks are quite limited when compared with VisualAge
with Envy but that's another discussion ;--). They are separate versions
of Smalltalk for that reason and it's a good thing too. (I use Susie
Smalltalk and Squeak Smalltalk in the Smalltalk.org web site for various
jobs - the right tool for the right job).
Some of the innovations that I've encountered or created will enable
Smalltalk to be a more powerful language while retaining all aspects of
Smalltalk - if they are adopted. (See my other postings in this group
and on Smalltalk.org for some of the details of those).
Other innovations that I've encountered or created however, alter the
Smalltalk language so much so that it's no longer really Smalltalk -
more powerful and highly influenced by Smalltalk but clearly not
Smalltalk anymore (at least to me). For this reason and others I'm
implementing ZokuScript which is highly influenced by Smalltalk but goes
beyond it enough that it isn't Smalltalk anymore. At the same time I'm
implementing ZokuTalk which is meant to be a version of Smalltalk.
Actually for leverage ZokuTalk will be converted to ZokuScript on the
fly and the ZokuScript equivalent will be compiled for execution.
In the meantime I regularly use the following Smalltalks for various
projects (paying and otherwise): Squeak, Susie, Dolphin, Visual Age,
Visual Works, Coke-Pepsi-idst, and less often others. Naturally as is
the way of a mobius system that evolves to it's next level I'm writing
ZokuScript/ZokuTalk in Smalltalk. Once the Zoku Execution Engine (not a
virtual machine) has reached a stage that it can run by itself
development will proceed self hosted by itself.
>
>> 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
Well even the Greeks and Babylonians got some things right even if some
of their ideas have been refined. As a general principle I concur and
support your efforts - as there is some overlap with some of the
solutions that I've been working on with Transactions and parallel
processing. However, I'm also grounded in the harsh realities of
concurrency control in a wide range of contexts - not all problems can
be solved by the solution you are presenting. To ignore that is to
ignore reality.
If you can however provide a proof I'd have to be adapt since the
science aspect of computing implies an evidence based approach.
All the best,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071025/4c4fa856/attachment.htm
More information about the Squeak-dev
mailing list
|