On 27 September 2012 20:02, P.H.Welch <P.H.Welch@xxxxxxxxxx> wrote:
<snipped>
 - occam-pi does enable "objects" to be communicated over channels in the
  most efficient way (i.e. by reference, if staying in the same memory
  space) and with complete safety against race hazards. ÂCurrently,
  these objects have to be declared MOBILE and are contiguous chunks
  of data (i.e. no links to other MOBILEs). ÂWe are proposing to remedy
  this (see slides 111-113, then 102-105 from the "occam Obviously" slides
  from CPA 2012: http://www.wotug.org/paperdb/show_proc.php?f=4&num=29).
'Occam Obviously' was the spur for me to write my ideas down and the basis of that thinking. The stack/heap differentiation is new to Occam but widely used (and considered essential) in many other languages.Â
Â
 - we have found mobile channel-ends to be crucially important for the
  modelling of complex systems - see the CoSMoS project:
   http://www.cosmos-research.org/demos/
  Without channel-end mobility, only pre-defined parallel networks can
  be built. Complex systems demand the construction/growth of networks
  as they run. ÂPassive data mobility is not enough.
I agree that this is worthwhile. ÂIt remains important that systems with mobile channels must be comprehensible. ÂIs it worth exploring certain special cases? Â
<Thinking aloud>
 For example, the 'server accept' case is likely to be a widely used pattern, where an arbitrary client requests a service from a service process via an AnyToOne (or AnyToAny) channel and wants a reply back. ÂThe client could send a mobile channel end to the server for the reply. ÂBut it doesn't have to be that explicit in this case. ÂThere may be an alternative clear syntax for the client to say 'here are my input parameters, please send the result directly back to me' without needing the mobile channel syntax, even though the mobile channel as we now understand it is how the server would operate under the hood. ÂThis is more a question of syntax than semantic, along the lines of a call channel.
</Thinking aloud>
My knowledge is limited as to what lies beyond the call channel pattern. ÂHow else can mobile channels be used? ÂI anticipate that lots of answers exist, although maybe not many established patterns yet.
Â
  Whether process mobility (the sending of processes down channels, which
  occam-pi supports) is necessary has still to be decided. ÂTechnically,
  they are not - there is a duality between process mobility and channel
  mobility (anything one can do, so can the other). ÂBut process mobility
  may give better powers of _expression_ sometimes.
Occam-Tau addsÂfunction mobility to the mix, and this is distinct from process mobility because the mobile functions are side-effect-free. ÂI hope Implementation would not be hard. ÂWithin a single memory space, passing a reference to a function along a channel would be sufficient. ÂAcross parallel processors, the same would be true within a given compiled & linked program. ÂI'm assuming therefore that the function's executable code is knownÂa priori.
Â
 - verification is essential, though mostly denied in commercial practice
  as impractical (and, therefore, unnecessary). ÂFor concurrency models
  other than those based on CSP, verification is hard indeed! ÂFor occam,
  see our examples in the "Cancellable Servers - a Pattern for Curiosity"
  slides from CPA 2012, based on proposals in the two "Self-Verifying"
  presentations at:
   https://www.cs.kent.ac.uk/research/groups/plas/wiki/IFIP_WG24/
I have an interesting recent
case history on the lack of verification of a concurrency model. This came about through using a large dose of implicit concurrency, which is hugely popular amongst many Scala developers. Our new website (for O2 selling iPhones) ran 25 times faster when we removed the particular non-blocking HTTP library that was using its own threads under the hood. I know of no way we could have predicted in advance that the threading would be so dreadfully broken; I'm just grateful we tried the alternative and measured the difference in spite ofÂthat developer community's version ofÂreceived wisdom.
Cheers,
Rick Beton