Joerg Beekmann  wrote:
> 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.
>

There is a debate that has been going on for at least 25 years about whether
message sending should be synchrounous (in the CSP or Limbo sense) - like
telephone calls - or asynchronous (e.g. actors) - like mail. It isn't as
fundamental as it looks at first since it is pretty easy to implement one in
the other. E.g. in Limbo one can communicate with a local process that
buffers messages and forwards them to the intended receipient when it is
ready to receive them. I prefer asynchrounous since it matches the inherent
properties of real-world communication - e.g. sending IP packets.

> 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.
>

This would be a good step forward but I wonder how well it would mesh with
current practice. And many dangers remain unless you have a one-to-one
mapping of threads and objects - see my earlier posts and those of Andreas
Raab.

I like languages where channels are the sole means of communication between
objects. Then they need to be made very low cost and have a nice syntax.

Best,

-ken kahn ( www.toontalk.com )