Re: Occam-Tau anyone???

[Michael <sparks.m@xxxxxxxxx>]

On 5 October 2012 22:07, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:
> Fred,
>
> Nice idea. My only quibble is that the part you left out --- "alternation (external choice)" --- is the very top one on my list of priorities! The splitting into two streams is easy in bash (i.e. tee), but ALT-ing them back together seems to be impossible, and using different "number" streams was NOT successful when I tried to get two STDINs to work. Entities breaking on either spaces or on '\n' seem natural units for such "channels" to deliver.
>
> Question (and I know I'm showing my ignorance here): what is the "aliasing" against which all the non-occam languages are unsafe?

I'm presuming the issue here is means 2 references to the same object
being held by two concurrent things. Most non-functional languages
have this issue when using threads (green threads) to implement
concurrency.

In particular if you sling an object down a channel, the sender has to
ensure that they don't use the same object again afterwards.

For example, consider a frame grabber. It grabs bytes representing
pixels, slings them into a frame object and then sends the frame
object out a buffer or channel - to be processed by an image
processor. For many implementations of message passing in a shared
memory environment, if the frame object is reused by the producer,
then the consumer sees the changes simultaneously.

As a result, in a shared memory environment it makes sense to use
metaphors that imply naturally that you shouldn't change it once it's
passed on - which is why I've chosen the metaphor of inboxes/outboxes
before. With a language that's concurrency aware you could could
instead sling around duplicates (or more realistically references to
duplicate proxies that have semantics more likely copy-on-write).

The reason I say non-functional languages is that like occam
functional languages also do not have this aliasing issue because of
the view that values are immutable. As a result once a value is passed
to another object -- be it a function, class, or process by any means
including channel-type comms -- what the sender does to the value is
irrelevant to the receiver.

It's plausible that if (in an imperative language) the objects passed
between concurrent things were in fact transparent STM stores, that
such imperative languages could gain the same sort of benefits as
things like occam and concurrent functional languages like scala and
erlang.

Indeed, they could have a significant advantage, because while this
aliasing issue normally causes problems, if the objects passed through
the channel are concurrent objects themselves, there are significant
fringe benefits if no duplication takes place.


Michael.