Ken Kahn wrote:
> Maybe one way to communicate these ideas is to imagine that each object is
> running on its own server. The server maintains the state of the object.
You
> have concurrency without race or deadlock worries. Just performance
worries


One language that implements concurrency in just this way is Inferno.
Synchronization between thread is via channels which to which you could
write and from which you could read. An extract from an inferno paper at
http://www.vitanuova.co.uk/inferno/papers/bltj.html:

   [one type]...is a built-in Limbo type called a channel (chan is the
keyword). 
   A channel is a communications mechanism in the manner of Hoare's 
   CSP[15]. Two processes that wish to communicate do so using a 
   shared channel; data sent on the channel by one process may be 
   received by another process. The communication is synchronous: 
   both processes must be ready to communicate before the data changes 
   hands, and if one is not ready the other blocks until it is. 
   Channels are a feature of the Limbo language: they have a declared 
   type (chan of int, chan of list of string, etc.) and only data of 
   the correct type may be sent. There is no restriction on what may 
   be sent; one may even send a channel on a channel. Channels therefore 
   serve both to communicate and to synchronize. ...

In practice all this means you don't need semaphores. The paper include some
expamples of how to build multi threaded UI's without at lot of
synchronization code.  

   [ui example waiting on user communications]... alt statement provides 
   control when more than one communication may proceed. Analogous to 
   a case statement, the alt evaluates a set of expressions and executes 
   the statements associated with the correct expression. Unlike a case, 
   though, the expressions in an alt must each be a communication, and 
   the alt will execute the statements associated with the communication 
   that can first proceed. If none can proceed, the alt waits until one 
   can; if more than one can proceed, it chooses one randomly. ...

I've oftent thought that the concurrency support in Smalltalk is strikingly
low level and difficult to abstract (compared to what can be done with
objects) and have toyed with implementing channels in Smalltalk several
times, it wouldn't get you to mega-concurrency but I think would make
writing multi-threaded code much cleaner since it provides a higher level of
abstraction to work at.

Infern an offshoot of plan9 was going to be used extensivly by Lucent as the
embedded language on in routers and such stuff. It was overrun by Java and
is now supported by via neova, http://www.vitanuova.co.uk/inferno/. Inferno
papers are at: http://www.vitanuova.co.uk/inferno/papers.html.

Joerg

Joerg Beekmann
beekmann at columbusgroup.com



-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Ken
Kahn
Sent: October 18, 2001 11:15 AM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Lots of concurrency


Lex Spoon wrote:

> Now here's where I get a little lost:
>
>
> > I agree. Mixing concurrency and shared state causes headaches that we
all
> > want to avoid. My answer is that there is no shared state and no process
> > state (there is no *position* in a computation to worry about - remember
I'm
> > getting rid of sequential composition). There are just concurrent
objects
> > that send messages asynchronously. E.g. actors. Though I'm arguing for
> > something a bit more flexible than actors where there can be multiple
mail
> > boxes, where mail boxes are first class, etc.
>
>
> I don't see how this can work in practice.  For a simple example, how
> would you do BouncingAtomsMorph in your system?  In Squeak, each atom
> currently has a position stored in an instance variable -- i.e., state.
> How do you get rid of the state in something like an atom bouncing
> around?  Move it into the messages?
>
> How does an atom decide when it is close to the edge of the screen and
> needs to bounce into a different direction?  And for bonus, how do atoms
> infect each other, i.e., how do you tell when two atoms of different
> color are near each other?
>

Sorry about the confusion. When talking to procedural programming types I
use the phrase "shared state" to mean data that can be altered by multiple
threads. In the context of pure object-oriented programming I should explain
this differently. I am not proposing to get rid of state. I agree with you
that that doesn't work despite the efforts of functional programming
researchers.

What is it that causes problems when mixing state and concurrency? It is
when there can be simultaneous access to the same state. If two threads are
both running code for a bank account object then those threads may interfere
with each other and leave the bank account in some inconsistent and
unpredictable state. I want to change things so that each object has its own
thread and no thread has more than one object so this problem goes away. And
asynchronous message sending means that if A sends B a message M1 and then
sends B message M2 that other messages from others might arrive between M1
and M2 and so A can't assume that B hasn't changed in the interim.

Maybe one way to communicate these ideas is to imagine that each object is
running on its own server. The server maintains the state of the object. You
have concurrency without race or deadlock worries. Just performance worries
;-)

Best,

-ken kahn ( www.toontalk.com )