On 27 September 2012 20:02, P.H.Welch <P.H.Welch@xxxxxxxxxx> wrote:
Â - 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? Â
Â 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.
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.