[python-uk] [pyconuk] Minimalistic software transactional memory

[Michael Sparks]

On Thursday 20 December 2007 07:55:11 Richard Taylor wrote:
> That is reasonable. There can be performance improvements from using
> separate read/write locks under certain loads, but I doubt that is an issue
> here. 

Indeed. I'm tempted to do value level locking at somepoint, but performance 
isn't likely to be an issue here.

> You won't find much on MASCOT unfortunately:
> http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Oper
>ation_and_Test gives you the bare bones but not much else.

But that gives me enough search terms to find this:
   http://www.object-forge.com/

And from that I should be able to ferret out more...

Which gives me:
http://www.object-forge.com/Release1.0/docs/abbref.zip

Which gives me a reference PDF! :-D

>Although I 
> currently work for the successor of the Royal Radar Establishment at
> Malvern, where the method was developed, I did not learn it here. I was
> taught it as part of my decree course at Aberystwyth in the late 80s.

It sounds really interesting and seems to have a fair amount in common with 
Kamaelia - with probably pools being the only thing really missing - though 
the tracker (the CAT) which is designed to track values & services looks 
*close* to being like pools. Not quite the same, but close. Our backplanes 
are similar in a way, but rather different as well (they're more ephemeral 
and more a pub/sub thing than a store/retrieve - which the pools appear to 
be).

Reading more of that PDF, it looks like our CAT (co-ordinating assistant 
tracker) is perhaps very much closest to MASCOT's pools, but because it's not 
been anything like an STM or similar it's been relatively crippled. 

The idea of being able to use the cat to produce a simple solution to the 
dining philosophers problem is quite amusing:

take forks... (pseudo python, ignoring various details)
not_have_forks = True
while not_have_forks:
   try:
      S = <get the store from somewhere>
      forks = S.using("fork.1", "fork.2")
      if forks["1"].value == None and forks["2"].value == None:
          forks["1"].value = id(self)
          forks["2"].value = id(self)
          forks.commit()
          not_have_forks = False
   except ConcurrentUpdate:
       time.sleep(random()) # random backoff - doesn't guarantee success
   except BusyRetry:
       time.sleep(random()) # random backoff - doesn't guarantee success
eat()
# Put forks back - should always succeed. Should. :-)
try:
    forks["1"].value = None
    forks["2"].value = None
    forks.commit()
except ConcurrentUpdate:
    pass
except BusyRetry:
    pass

I'd not even really bothered with the dining philosopher's problems because 
it's not mapped to a real world problem so far for us, but that PDF made it 
clear that's what we can do on page 16... 

In Kamaelia, a component appears to be equivalent to mascot activity. (We 
allow generators, threads and (experimentally) processes to be the activity 
part a component)

The linkages between outboxes and inboxes appear to be directly equivalent to 
a MASCOT channel. Furthermore, given under the hood we collapse inboxes and 
outboxes together as an optimisation when a linkage is made, the relationship 
between llnkage/box and a MASCOT channel is quite obvious...

A key difference though is that channels appear to exist independently in a 
system - this I guess means that the MASCOT activities need to know the 
global/subsystem name of the channel upfront ? (Whereas, effectively, we 
provide a local alias which the system wires up at runtime) Hmm... looking at 
this more, I'm guessing no - because it looks like these can be arguments. 
Reading more, it looks like all our inbox/outboxes default to being directly 
equivalent to MASCOT argument connections.

However, component is also our unit of composition so component is also our 
equivalent to a MASCOT subsystem. Though we do have Chassis components whose 
purpose is largely to have something you bolt other components to.

MASCOT set's appear to be very similar (from description) to our concept of 
pipelines and graphlines. It also appears that the fact we can introspect 
running systems to look at linkages/boxes/components visually seems to be 
something we have in common (based on object forge descriptions!)

You may find this page relatively amusing:
    * http://kamaelia.sourceforge.net/Docs/NotationForVisualisingAxon

(That notation isn't widely used because the visualisation/visual creation 
tool we use doesn't use that notation, but the doc above was one of the 
earliest sketch ideas for a notation)

Reading through that PDF it looks like somethings we do make life simpler 
(people appear to have to use locking directly in that implementation).

> Anyone else out there still using MASCOT?

I suspect I'm going to be ferreting out as much information about MASCOT as I
can :-)

Very many thanks for the feedback and search terms - amazingly useful! :-D

Merry Christmas :-)


Michael.