Concurrent Squeak (was Re: election details *PLEASE READ*)

J J azreal1977 at hotmail.com
Fri Feb 23 15:44:13 UTC 2007


Yes, I think it could be done fairly easily.  To make it easier I would want 
some kind of "spawn" to spawn a process (calls OSPluginFork where 
supported), and a package that lets me do something like:

ConcurrencySystem sendMsg: message to: somePID  "where somePID can be local 
of off box"

And the process recieves it with something like:

ConcurrencySystem
  recieveMsgOfType: someMessageDescriptionThing
  orType: someOtherOne
  orType: systemNetworkFailure
  ofType: systemProcessFailure

Something like that, the way Erlang has. :)

>From: "David T. Lewis" <lewis at mail.msen.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Concurrent Squeak (was Re: election details *PLEASE READ*)
>Date: Fri, 23 Feb 2007 07:09:45 -0500
>
>You can do approach (3) with an ordinary Squeak image if you are
>using a unix platform (including OS X, I think) with OSProcess. Use
>#forkHeadlessSqueakAndDo: to start the "threads", and connect them
>with OSPipes. The endpoints of an OSPipe are FileStreams, so you
>can read and write serialized objects between the images. The
>#forkSqueak turns out to be surprisingly fast and memory efficient.
>
>I'm not up to speed on Croquet, but some variant of this technique
>might be a convenient way to start up a large number of cooperating
>Croquet images, presumably using sockets instead of OSPipe.
>
>Dave
>
>On Thu, Feb 22, 2007 at 10:21:42PM -0800, Andreas Raab wrote:
> > Nice summary. The only thing I have to add is that your approach (3) is
> > how Croquet works. We currently don't do it inside a single image but we
> > have been talking about it and at some point we will get around to it.
> >
> > Cheers,
> >   - Andreas
> >
> > J J wrote:
> > >
> > >Afaik there are 3 ways of handling true concurrent execution (i.e. not
> > >green threads):
> > >
> > >1) Fine-grained locking/shared thread state:
> > >
> > >The old way of running heavy weight threads, sharing memory across
> > >threads and using some kind of locking to protect against race 
>conditions.
> > >
> > >Positive:  Hrm, well I guess there is the most support for this, since
> > >it is probably the most common.  If you don't use any locking but only
> > >read the data shared this is very fast approach.
> > >
> > >Negative: It simply doesn't scale well.  It also doesn't compose well.
> > >You can't simply put two independently created pieces of code together
> > >that use locking and expect it to work.  Stated another way,
> > >fine-grained locking is the manual memory management of concurrency
> > >methodologies [1].  If any part of your code is doing fine-grain
> > >locking, you can never "just use it" somewhere else.  You have to dig
> > >deep down in every method to make sure you aren't going to cause a
> > >deadlock.
> > >
> > >This one would probably be very hard to add to Squeak based on what 
>John
> > >said.
> > >
> > >2) Shared state, transactional memory:
> > >
> > >Think relational database.  You stick a series of code in an "atomic"
> > >block and the system does what it has to to make it appear as the 
>memory
> > >changes occurred atomically.
> > >
> > >Positive:  This approach affords some composability.  You still should
> > >know if the methods your calling are going to operate on memory, but in
> > >the case that you put two pieces of code together that you know will,
> > >you can just slap an atomic block around them and it works.  The system
> > >can also ensure that nested atomic blocks work as expected to further
> > >aid composability.  This approach can often require very few changes to
> > >existing code to make it thread safe.  And finally, you can still have
> > >all (most?) of the benefits of thread-shared memory without having to
> > >give up so much abstraction (i.e. work at such a low level).
> > >
> > >Negative:  To continue the above analogy, I consider this one the
> > >"reference counted memory management" of options.  That is, it works as
> > >expected, but can end up taking more resources and time in the end.  My
> > >concern with this approach is that it still does need some knowledge of
> > >what the code you are calling does at a lower level.  And most people
> > >aren't going to want to worry about it so they will just stick "atomic"
> > >everywhere.  That probably wont hurt anything, but it forces the system
> > >to keep track of a lot more things then it should, and this bookkeeping
> > >is not free.
> > >
> > >This one would also require some VM (probably very big) changes to
> > >support and could be tough to get right.
> > >
> > >3) Share nothing message passing:
> > >
> > >Basically, no threads, only independent processes that send messages
> > >between each other to get work done.
> > >
> > >Positive:  This approach also allows a high level of composability.  If
> > >you get new requirements, you typically add new processes to deal with
> > >them.  And at last, you don't have to think about what the other "guy"
> > >is going to do.  A system designed in this manner is very scalable; in
> > >Erlang for example, a message send doesn't have to worry if it is
> > >sending to a local process or a totally different computer.  A message
> > >send is a message send.  There is no locking at all in this system, so
> > >no process is sleeping waiting for some other process to get finished
> > >with a resource it wants (low level concerns).  Instead a process will
> > >block waiting for another process to give him work (high level 
>concerns).
> > >
> > >Negative:  This requires a new way of architecting in the places that
> > >use it.  What we are used to is; call a function and wait for an
> > >answer.  An approach like this works best if your message senders never
> > >care about answers.  The "main loop" sends out work, the consumers
> > >consume it and generate output that they send to other consumers (i.e.
> > >not the main loop).  In some cases, what we would normally do in a
> > >method is done in a whole other process.  Code that uses this in
> > >smalltalk will also have to take care, as we *do* have state that could
> > >leak to local processes.  We would either have to make a big change how
> > >#fork and co. work today to ensure no information can be shared, or we
> > >would have to take care in our coding that we don't make changes to 
>data
> > >that might be shared.
> > >
> > >I think this one would be, by far, the easiest to add to Squeak (unless
> > >we have to change #fork and co, of course).  I think the same code that
> > >writes out objects to a file could be used to serialize them over the
> > >network.  The system/package/whatever can check the recipient of a
> > >message send to decide if it is a local call that doesn't need to be
> > >serialized or not.
> > >
> > >[1] The big win usually cited for GC's is something to the effect of
> > >"well, people forget to clean up after themselves and this frees up
> > >their time by not making them".  But really, the big win was
> > >composability.  In any GC-less system, it is always a nightmare of who
> > >has responsibility for deleting what, when.  You can't just use a new
> > >vendor API, you have to know if it cleans up after itself, do I have to
> > >do it, is there some API I call?  With a GC you just forget about it,
> > >use the API and everything works.
> > >
> > >_________________________________________________________________
> > >Win a Zune??make MSN? your homepage for your chance to win!
> > >http://homepage.msn.com/zune?icid=hmetagline
> > >
> > >
> > >
> >
>

_________________________________________________________________
Find what you need at prices you’ll love. Compare products and save at MSN® 
Shopping. 
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701




More information about the Squeak-dev mailing list