[Squeak-e] Re: Concurrency models for Squeak-E (was: squeak-e and ANSI Smalltalk)

Robert Withers rwithers12 at attbi.com
Sun Feb 2 13:35:42 CET 2003

On Saturday, February 1, 2003, at 07:56 PM, Mark S. Miller wrote:

> I know that E's model of concurrency does work well with capabilities, 
> and
> can be added to sequential Squeak as Rob has been doing.


I started down the path toward E due to an interest in building a 
concurrency model in squeak.   I was initially looking at 
ConcurrentSmalltalk and had coded a Secretary class for that purpose.  
In ConcurrentSmalltalk, they introduce a mechanism in the control flow, 
like many other concurrent languages I believe, where the receiver 
explicitly receives the message sent, and the sender would explicitly 
receive the return value.  This suddenly started looking like the use 
of concurrency would cause all kinds of explicit handshaking to 
propagate into the image proper.

There were many aspects of your concurrency model that attracted me, 
but I suppose the biggest was the promise.  The promise in E is more 
than a promise of a value to be returned, it was the promise of an 
object being returned.  With this slightest of shifts, you had decided 
that a program could send messages to the promise.  The contract of the 
promise is 1) it will resolve to an object, which may be broken and 2) 
all messages sent to the promise will be forwarded to the resolved 

After reading more about the concurrency model and the distribution 
model, it became clear that this model goes further.   When messages 
are sent to a promise for a previous message send, that happened to be 
to a receiver that was remote, then those subsequent message sends 
would be sent to the remote location of the original receiver.   If the 
resolved object for the promise is co-located with the original 
receiver, then you could immediately send the subsequent messages to 
that object in the remote image.  If the resolved object for the 
promise is located in yet a second remote image, then the messages 
would be sent from the first remote image, directly to the new 
receiver's image.  This is quite remarkable.

To make all of this work in  partially-order fashion - I think that was 
the reason - you introduced the event-loop concurrency model.  This is 
very similar to an UI thread event loop, so it makes a lot of sense in 
squeak.  This sealed my fate and here we are.  :)

> As I recall, PPS2.5
> had a similar model, but less preemptive. (Where is Squeak's model
> documented?)

I searched and searched and couldn't find any write up on this.  Here 
is a handful of links: http://minnow.cc.gatech.edu/squeak/1602 ,  
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html .  Of course 
the source code is there, but it doesn't really have any comments.  I 
think the right way to describe it is preemptive multitasking, where a 
higher priority process may preempt a lower priority process.  It has 
Semaphores for coordination.  I worked on a LindaTalk implementation, 
for awhile.

> I know that David Reed has proposed an interesting concurrency and
> distributed computing model for Croquet. I'd love to see a description 
> of it.
> I don't yet know enough to comment.

I would also very much like to hear about his work.  Is there someone 
who could invite him to join us, perhaps?

> Finally, Smalltalk isn't just a system. It stand for a philosophy named
> "object-oriented programming".

Actually, Alan Kay is attributed with saying something along the lines 
of wishing he had termed it message-oriented programming, since the 
focus should be on the communication rather than the things.  The power 
is in the interactions themselves, rather than in the agents 

>  From my sense of what this philosophy is,
> capabilities could be termed "object-oriented security". (This coinage 
> by
> Dean Tribble.) The virtues of capabilities are an extension of the 
> virtues
> of oo. Likewise, I believe E's event-loop concurrency control model is 
> the
> extension of the oo philosophy into the concurrency realm, which we 
> try to
> make clear especially at 
> http://erights.org/elib/concurrency/event-loop.html
> and http://erights.org/elib/concurrency/turns.html . In these three 
> cases --
> objects, security, concurrency -- the issues can be seen in the terms 
> the
> economist F.A. Hayek explained: How do plans come to be coordinated 
> with
> each other (message passing) without disrupting each other 
> (encapsulation)?
> For an object-oriented view of Hayekian economics, see
> http://www.erights.org/talks/categories/index.html .

This is a great paper.  It is difficult to read and there is a lot of 
new terminology to digest, but the thesis is unique and powerful.  The 
economics of development, or rather the development of economics.  
Well, we have a another store front, here. :)

> So I hope we make Squeak-E a system that not only works, but one 
> that's also
> a purer expression of the philosophy that Smalltalk has always stood 
> for.

I sure we will spend a good part of our time ensuring that this is 
indeed the case.  :)


More information about the Squeak-e mailing list