RE: JCSP, CSP Networking, and other some other points

[Kevin Chalmers <k.chalmers@xxxxxxxxxxxx>]

We do have output guards in JCSP, by using the AltingBarrier underneath.
Not all outputs are guarded (there is a performance hit), so standard
channels are still input guarded only.  Take a look at
One2OneChannelSymmetric in the JCSP documentation.

Promela is nice, but of course is a modelling language.  Output guards are
tricky due to the selection process; hence until we had a fast multi-way
sync we couldn't provide fast resolution on output guards.  However, unlike
Promela, we do not have shared guards at the moment in JCSP.  If you avoid
shared guards in your Promela/Spin model, then you can almost exactly
implement your model in JCSP.  I did this for the new JCSP networking
protocol and architecture (although I did the JCSP first).

-----Original Message-----
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Teig, Oyvind
UTCFS
Sent: 25 February 2009 09:59
To: Ruth Ivimey-Cook; occam-com@xxxxxxxxxx
Cc: Andrzej Lewandowski; Adam Sampson
Subject: SV: JCSP, CSP Networking, and other some other points


Not having read all the words this morning..

How about using channel output in guards?
I work with Promela at the moment, it is VERY nice!
I know the transputer designers had their reasons to rule this out (was it
the distributed architecture and fault modes?). How about a new keyword:
DEAD?

ALT -- will send on any picked channel if not full or receivers
  old_occam_channel ! data
    ...  sorry
  new_occam_channel ! data
    ...  good!
  DEAD ? channel_index
    .... disconnect dead channel
  TRUE & clock ? AFTER 1985 PLUS 24
    ...  on time to do this now

especially when a channel has capacity, and sooner or later will block.
Does JCSP have this?

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: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] På vegne av 
> Ruth Ivimey-Cook
> Sendt: 25. februar 2009 01:06
> Til: occam-com@xxxxxxxxxx
> Kopi: Andrzej Lewandowski; 'Adam Sampson'
> Emne: Re: JCSP, CSP Networking, and other some other points
> 
> Andrzej Lewandowski wrote:
> > Interesting. But... Occam, transputer, Kroc, all ARE THINGS OF THE 
> > PAST. Why you are playing with dead bodies instead of using your 
> > talent and knowledge to address problems that are current?
> >   
> I'm finding it hard to answer this thread - there are so many 
> conflicting ideas and requirements as Andrzej's note shows. 
> His comment reminds me of the old adage "A people who forget 
> their history are doomed to relive it". There are indeed in 
> occam and the transputer many ideas that are just as relevant 
> to today's world as ever. For some details see my conference 
> paper "//Legacy/ of the /transputer"/. 
> /However, there is a perception problem: that because (for 
> mostly commercial reasons) the transputer processor itself 
> "failed"**, that occam and the transputer were necessarily a 
> Bad Thing and to be condemned en-masse. This is unfortunate.
> 
> I can see that the current demand for multi-core systems is a 
> great opportunity for CSP patterns to be used, and agree that 
> without significant penetration into the mindset that will be 
> lost. Perhaps this is an area that WoTUG can spend some money 
> - out and out advertising and sponsorship? Anyway, the other 
> side of the coin is that people are wedded to their existing 
> ideas and systems, sometimes by commercial necessity.
> 
> The main barrier I have at my own workplace is that pretty 
> much all of the >1 million line core codebase of the software 
> is written in plain old C - and mostly to C89 standards - and 
> there is a significant portability requirement.  Some, in 
> outlying areas, is in C++ or Java. 
> New languages like C# and Ruby and Python are nowhere in sight.
>
> The consequence is that from a work viewpoint I'm very 
> interested in where a self-contained C-language CSP threads 
> library might go, but bring C++ in and I lose interest again.
> 
> If we could come up with a serious competitor to the pthreads 
> library, written in portable C, that would be wonderful. If 
> it had versions in 
> Embedded-C++ and C# that would be even better. I'm not convinced that
> Java is a platform that needs CSP in the same way, but I 
> guess others are, so add in Java if you wish.
> 
> Regards,
> 
> Ruth
> 
> P.S. I am (slowly) writing a new book describing occam-pi; at 
> present it's about 100 pages of an early draft of the core 
> language. I'm interested in feedback - if you would like to 
> see it please write and ask.
> 
> **there are still transputers buried inside an awful lot of 
> the set-top boxes of the world.
> 
> > -----Original Message-----
> > From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On 
> Behalf Of Adam 
> > Sampson
> > Sent: Tuesday, February 24, 2009 12:50 PM
> > To: occam-com@xxxxxxxxxx
> > Subject: Re: JCSP, CSP Networking, and other some other points
> >
> > Bob Gustafson <bobgus@xxxxxxx> writes:
> >
> >   
> >> I rather enjoyed reading Geraint Jones's two books on Occam. The 
> >> latest, with Michael Goldsmith - "Programming In Occam 2 (2nd 
> >> Edition) (Paperback)" is available on Amazon.
> >>     
> >
> > Geraint Jones has made an updated version available for free online:
> >   
> > 
> http://www.comlab.ox.ac.uk/people/geraint.jones/publications/book/Pio2
> > /
> >
> > The KRoC and Transterpreter implementations of occam-pi are 
> > open-source and available for a variety of operating 
> systems. KRoC is 
> > included with some Linux distributions, but it's under active 
> > development, so you're probably better off downloading the 
> latest version from us:
> >   http://projects.cs.kent.ac.uk/projects/kroc/
> >
> > The examples from the book will work directly in KRoC provided you 
> > wrap them in an appropriate top-level process (e.g. "PROC 
> main (CHAN 
> > BYTE
> > out)") -- but the extra facilities available in occam-pi 
> over occam 2 
> > can be used to simplify a lot of the code.
> >
> >   
> 
> 
> 




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