Re: Occam-Tau anyone???

[Larry Dickson <tjoccam@xxxxxxxxxxx>]

On Oct 5, 2012, at 2:28 PM, Michael <sparks.m@xxxxxxxxx> wrote:

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

Thanks, Michael. I think functional languages have their place, but so do things like ping-pong and circular buffers, so the more general occam way makes sense. If you want to pass data references, follow the "hardware/software equivalence" principle and model them as data containers being passed around by "sneakernet". Use extra bits to remember whether a slot has a container and whether that container contains data. A model of another thing is a (read-only) 2D barcode being photographed by several receivers at once, with a mechanism (series switches) for them all to notify the sender that they have captured it; otherwise the sender doesn't know when to feel free to change it.

Next question: what are transparent STM stores?

Larry