RE: There is always the lecture circuit

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

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