[python-uk] [pyconuk] Minimalistic software transactional memory
Michael Sparks
ms at cerenity.org
Thu Dec 20 12:26:15 CET 2007
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.
More information about the python-uk
mailing list