RE: There is always the lecture circuit

["Eric Verhulst" <eric.verhulst@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Oyvind,


I would not consider this as an overflow buffer. The buffer decouples
senders and receivers as long as their is space in the buffer. Else they
become "synchronuous" again. The same happens when the buffer is full. 

The _async services are a more general case with the decouplig being total
until the reserved capacity for decoupling has been depleted (= number of
allocated pool packets used up).

In general, your picture below only shows the dataflow, but that is only
part of the full picture. We have entities (=processes or tasks) that
interact. The interaction is made explicit by the use of the hub that are
Guarded Atomic Actions. The synchronisation is the guard and the action the
consequence. But contrary to pure CSP channels, the guard can be almost
anything (it is a predicate). Hence the guard is valid when it boolean
conditions hold. E.g. it can something like:

1. Sender wants to send a packet
AND
2. Receiver wants to receive a packet
AND
3. There is room in the buffer.
AND
4. Time_out not expired

(IF 1 AND 2 AND 3 AND 4 => synchronisation)

ELSE
	WAIT (_W)
OR
	FAIL (_NW)
OR (TimeOut expired)  
 	FAIL  (_WTimeOut)

The action then is: packet passed on from sending side to receiver side.
(implementation: relevant content copied).

With an _async service, the synchronisation is done in 2 steps. A sender
does first 1, a receiver first 2 without waiting. Hence it is like posting
an option to synchronise.

Some info is on the website, else see the API manual at
http://www.altreonic.com/drupal64/node/15

In general, everything is somewhere always synchronuous (and that's best
because resources are always bounded).
What the hub does different is that the synchronisation (read: interaction)
is decoupled from the processes. One result is generality, but also a hub
can be anywhere in the network and can even be defined by the user). It also
povides N-to-N semantics, whereas channels are tied in with the two
processes at either side and only know one type of guard.

In all honesty, we still have some work in formalising the hub as a GAA.
E.g. in an application the Guard could be "the temperature was higher than
the threshold" and the action "switch on the motorpump". This allows us more
or less to claim that OpenComRTOS is more than an RTOS but a new concurrent
programming paradigm for application development.


Eric  
 



-----Original Message-----
From: Teig, Oyvind UTCFS [mailto:Oyvind.Teig@xxxxxxxxxxxxxxxx] 
Sent: donderdag 26 februari 2009 12:39
To: eric.verhulst@xxxxxxxxxxxxxxxxxxxxxx
Subject: SV: There is always the lecture circuit

Eric!

This is interesting. The asynch thing you are taking about is an advanved
version of an overflow buffer that cannot overflow?
                    -----------                   ------------	
                    |InputBuff|-------------->Data|          |
-------->Data-------|with     |
|OutputBuff|----------->Data
                    |capacity |synch<-------------|	       |
                    -----------                   ------------
                        |
                        |
                        V
                    (overflow)

Is there a description like you mail on your site?
Perhaps I could mention it on a post I'm trying to write at
http://oyvteig.blogspot.com/2009/02/007-synchronous-and-asynchronous.html


Med vennlig hilsen / sincerely
Øyvind Teig

--
Øyvind Teig
Senior dev.eng./utviklingsingeniør, M.Sc.
Autronica Fire and Security AS
A UTC Fire & Security Company
Tlf: +47 7358 2468
Fax: +47 7358 2502
Mob: +47 9596 1506
oyvind.teig@xxxxxxxxxxxxxxxx
www.autronicafire.no
home.no.net/oyvteig/pub - Publications

 

> -----Opprinnelig melding-----
> Fra: Eric Verhulst [mailto:eric.verhulst@xxxxxxxxxxxxxxxxxxxxxx] 
> Sendt: 26. februar 2009 11:55
> Til: 'Kevin Chalmers'; Teig, Oyvind UTCFS; 'Bob Gustafson'; 
> occam-com@xxxxxxxxxx
> Kopi: oyvind.teig@xxxxxxxx
> Emne: RE: There is always the lecture circuit
> 
> 
> I would like to point out that there is a no compromise 
> "middle-way" that we applied in OpenComRTOS. We use what we 
> call "hubs" as interaction entities between tasks/processes.
> 
> A Hub is basically a "Guarded Atomic Action" but because the 
> Guard (we call it the synchronisation predicate) can be 
> defined independently as well as the Action (we call that the 
> action predicate), it can do a lot more than a synchronised 
> channel can and still be safe (the design was formally 
> developed and verified). Buffering is one of the possible 
> sub-actions, but is constrained because everything is based 
> (under the hood mostly) on packet switching. Nevertheless, 
> task can synchronise using blocking, non-blocking and 
> blocking with timeout semantics. 
> 
> We also defined an _async variant. This works in two phases. 
> First of all the sender has to allocate a packet explicitly 
> from a packet pool. He can then send the packet to a hub 
> without waiting. The receiver can do something similar. He 
> can e.g. issue 3 receive_async calls and then later on pick 
> them up after the senders has done their thing, later on 
> returning the packets to the pool (the whole system is fully 
> distributed). I must admit that while the semantics of a 
> send_async is trivial, the semantics of a receive_async or 
> not. (hence the notion of two-phase services). Nevertheless, 
> while we provide events, semahores, fifos, memory pools and 
> resources/mutex hub implementations, we deliberately 
> abstained from "pipes" as they assume infinite buffers which 
> is never the case certainly not in the mebedded world (I call 
> that a lazy programmer's object).
> 
> Is this still CSP ? We call it a pragmatic superset of CSP. 
> In order to achieve the same in occam/CSP one would need to 
> insert each time a process in the channels that provides the 
> hub behaviour. Another difference is that the scheduler 
> provides full preemption, so no need for things like poison channels. 
> 
> Benefits: safe and small. A fully distributed implementation 
> can be as low as 2K Byte (one hub type only) whereas the 
> average code size is about 5 KB t 10 KB for a full version 
> (depends a lot on the target processor). It also works on 
> distributed targets, even on top of Win32 and Linux. So it 
> covers from multi-core to WAN type systems.
> 
> As this thread was also about promoting the concept of 
> CSP-like solutions (I fully agree that what the mainstream 
> community e.g. in the multi-core association is pushing is 
> horrifying, they clearly have never learned about 
> transputers, occam and CSP and hence ae reinventing prior 
> knowledge), it is my pleasure to announce that OpenComRTOS 
> was nominated with the Embedded Award. The final winner will 
> be announced next week at Embedded World in Nuremberg. 
> As you see, the mainstream community took note.
> 
> (if you wanna play, the Win32 version can be downloaded for 
> free at www.altreonic.com. Linux will be posted in the next weeks).
> 
> Eric Verhulst
> 
>   
> 
>  
> 
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf 
> Of Kevin Chalmers
> Sent: donderdag 26 februari 2009 10:21
> To: 'Teig, Oyvind UTCFS'; 'Bob Gustafson'; occam-com@xxxxxxxxxx
> Cc: oyvind.teig@xxxxxxxx
> Subject: RE: There is always the lecture circuit
> 
> "Running tasks in isolation and communicate via async messages "
> 
> Most likely it's the fire and forget and hope the buffer 
> doesn't overflow variety - Erlang style concurrency.  This 
> seems to be the current method everyone is interested in 
> (Erlang, Scala actors, F# Async Mailboxes, Microsoft 
> Concurrency and Coordination Runtime).  There is sometimes 
> some form of guard available, be it one that allows checking 
> of the incoming message, or selection of one from multiple inputs.
> 
> Kevin
> 
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf 
> Of Teig, Oyvind UTCFS
> Sent: 26 February 2009 08:24
> To: Bob Gustafson; occam-com@xxxxxxxxxx
> Cc: oyvind.teig@xxxxxxxx
> Subject: SV: There is always the lecture circuit
> 
> 
> From
> http://www.ddj.com/go-parallel/blog/archives/2009/02/herb_sutt
> er_isn.html
> 
> "Running tasks in isolation and communicate via async messages "
> 
> Is this the same as a buffered channel, that blocks when it's 
> full (like in Promela),
>   or pipes (with some ALTing semantics)
>     or send and forget into commen message queue (one per pri) 
>       where it's not possible to stop a message arriving, 
> like with guards?
>         and no WYSIWYG semantics?
>           Handling started sessions in "peace" is difficult 
> with "async messages",
>           because a process often becomes its own scheduler.
> 
> Letter to Edward A. Parrish, The Editor, IEEE Computer. Peter 
> Welch (University of Kent, UK) et al.
> http://www.cs.bris.ac.uk/~alan/Java/ieeelet.html (1997)
> 
> A CSP Model for Java Threads (and Vice-Versa). Peter Welch. 
> Jeremy M. R.
> Martin. Logic and Semantics Seminar (CU Computer Laboratory) 
> (2000) 
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/csp-java-model-6up.pdf
> 
> 
> Med vennlig hilsen / sincerely
> Øyvind Teig
> 
> --
> Øyvind Teig
> Senior dev.eng./utviklingsingeniør, M.Sc.
> Autronica Fire and Security AS
> A UTC Fire & Security Company
> Tlf: +47 7358 2468
> Fax: +47 7358 2502
> Mob: +47 9596 1506
> oyvind.teig@xxxxxxxxxxxxxxxx
> www.autronicafire.no
> home.no.net/oyvteig/pub - Publications
> http://oyvteig.blogspot.com/
> 
>  
> 
> > -----Opprinnelig melding-----
> > Fra: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] På vegne av Bob 
> > Gustafson
> > Sendt: 25. februar 2009 23:55
> > Til: occam-com@xxxxxxxxxx
> > Emne: There is always the lecture circuit
> > 
> > I think Herb Sutter was a C++ expert.
> > 
> > Now he is into concurrency, parallelism, etc.
> > 
> > http://www.ddj.com/go-parallel/blog/archives/2009/02/
> > herb_sutter_isn.html
> > 
> > =======
> > 
> > With more promotion, the occam, JCSP, CSP Networking crew 
> can get into 
> > the act too.
> > 
> > Bob G
> > 
> > 
> 
> 
> 
> 
> Edinburgh Napier University is the best modern university in 
> Scotland* and number one in Scotland for graduate 
> employability** (*Guardian University Guide 2009) (**HESA 2008)
> 
> This message is intended for the addressee(s) only and should 
> not be read, copied or disclosed to anyone else out-with the 
> University without the permission of the sender.
> It is your responsibility to ensure that this message and any 
> attachments are scanned for viruses or other defects. 
> Edinburgh Napier University does not accept liability for any 
> loss or damage which may result from this email or any 
> attachment, or for errors or omissions arising after it was sent.
> Email is not a secure medium. Email entering the University's 
> system is subject to routine monitoring and filtering by the 
> University.
> Edinburgh Napier University is a registered Scottish charity. 
> Registration number SC018373
> 
> 
> 
>