Advanced concurrancy

[Michael Sparks]

Peter Tillotson wrote:

> I've not yet had a chance to try some examples, but i've looked through
> the documentation. It feels quite familiar, 

It hopefully should. The approach is based essentially on an asynchronous
hardware approach, on the recognition that the fundamental reason that
hangs together is because it can be reasoned about in a similar manner to
CSP. (That naturally leads to similarities of course with Occam)

> but i'd say that it is closer to Jade, the fipa (federation of intelligent
> physical agents) compliant agent framework 

Thanks - I've not come across those - I'll have to take a look at that in
detail. (With a cursory look, they sounds similar to an application area a
colleague is interested in investigating)

> than CSP or pi calculus.  I like the behaviour 
> (component microthread) model,  but the advantage of CSP / pi calculus is 
> that the resulting distributed system remains open to mathematical
> analysis.

Indeed. However, by trying to have the same basic limitations in the system, 
Kamaelia should be amenable to the sort of approaches taken by hardware
verification systems. It's possibly worth mentioning that there is one
person at BBC R&D who is extremely interested in applying CSP style
analysis techniques to Kamaelia systems whom I sure would be interested in
chatting to you. (Indeed the similarities between Kamaelia and CSP is
biggest reason for his interest :-)
 
The idea of a verification system for software that is actually in use for
real world systems would be extremely nice/useful to have (though not
simple to achieve).

FWIW, I am interested in hearing suggestions on changing the system to make
it more amenable to mathematical analysis. (Largely because I'm a fan of
formal methods where possible, but pragmatically view TDD as the current
most practical way of getting towards the levels of reliabiliy aimed for by
formal methods)

> For concurency its is the best framework i've seen :-) 

Thanks!

> Have you come across the pylinda tuplespace implementation. It might be
> well worth a  look. 

I have, and I liked what I saw :)

> I might be barking up the wrong tree - but it seems to me that 
> there could be considerable overlap between tuplespaces and mailboxes,

Probably the closer match is the co-ordinating assistant tracker (I can
see what you mean though). That provides a basic global key/value
store/retrieve service, which in a concurrent system is probably most
akin to a Linda tuplespace. In a biological system it's more akin to the
hormonal system which is more of the model I like to think of as to /when/
to use that part of the system. (Evolution having more 'experience' than
me on how to build a massively concurrent system after all !!)

It's generally only used at present for one of two purposes:
   * Finding services that already exist (so that we don't try to open two
     displays for example)
   * Stats collection.

Using a Linda tuplespace there would be an interesting next move, however
we generally only extend the system based on specific need rather than
exploring architecture (Which I'm sure you understand!).

> though you did mention that you were moving towards twisted as the
> underlying platform for the future.

Perhaps not underlying, but definitely interoperating with (It seems rather
wasteful to reinvent wheels).

> I'm quite interested in the mini version and also using the modules as
> mobile code rather than installing it formally. 

I'll document it slightly better and post up on the website in the next 48
hours or so. In the meantime, the optimisation test which includes a
slightly modified mini-axon can be found here:

   http://cvs.sourceforge.net/viewcvs.py/kamaelia/Sketches/OptimisationTest/

Specifically the file "simplegame.py". This includes a cutdown version of
Axon that's about 100 lines long (lines 41 - 144 specifically), with the
important classes being:

      class microprocess(object):
      class newComponent(object):
      class scheduler(microprocess):
      class component(microprocess):
      class send_one_component(component):
      def linkage(source,sink):

> I'll probably zip the Axon directory and distribute the zip with the code,
> adding the zip to  the python path dynamically.

Sounds interesting. If you go ahead with this we'd be interested in hearing
how you get on.

Best Regards,


Michael.