My knowledge of transactional memory is, frankly, pretty limited. I listened incredibly enthusiastically at OSCON 2007 to Simon Peyton-Jones talk about it. (Slides available too). He’s a great speaker, and I got the gist of the talk, but I wasn’t ready (and still haven’t gathered myself) to make a leap into some of the new kid languages (Haskell, in particular) to try all this stuff out.

So at a brief reading of the API and description, it looks Michael has implemented the critter. So far, all the fiddling I’ve done has taken advantage of just a single core – in short, the little tasklets aren’t running concurrently – they’re explicitly sharing back and forth. Michael’s clearly thought further down the road there and determined that it would be nice to get all 8 cores of an Octo-Mac into the action. (Well, I expect that’s not QUITE what he though, but that was my immediate translation of it)

Mixing Axons as tasklets and threads, and you can do it. Axon’s got all the components to drive that thing hard. And as soon as you do that, you loose the safety net that I counted on earlier and need something exactly like STM.

3 thoughts on “more concurrent python goodies”

Incidentally, if you only use the boxes interface in Kamaelia, and limit usage of services to generator components the Kamaelia is threadsafe (though a service can still be a thread). A service is something like a Backplane, the Selector, PygameDisplay, etc

The border case is accessing a service from a thread. It’s *just* possible to allocate a service as it’s shutting down in a threading environment. It’s incredibly unlikely, but possible. This is due to use of the co-ordinating assistant tracker. (The CAT is to Kamaelia systems what unix environment variables are to Unix programs – or what hormones are to the neural system in biology (ish))

The reason for implementing STM (needs a friendlier name really – versioned shared variables maybe?) is to eradicate that corner case. The fact that it’s also useful to enable multicore applications on python VM’s without a GIL is really quite neat too. (eg on ironpython threads can run on seperate CPUs, so this provides a means for natural scaling there I suppose) Not sure if mono (and hence ironpython) runs on an opto-mac though 🙂

Hm… If this was running on a multicore machine, running on Iron Python running multiple schedulers in their own threads (and hence across CPUs) and then distributing microprocesses across them using STM as the implementation of the CAT would allow for naturally scaling parallelism without any faff at all. Potentially without any real modification to existing Kamaelia apps at all.

Pity I’ve only got a single core 🙂 It’d be a lovely proof of concept though.

Hey… I don’t seem to have your email address stored anywhereand wasn’t sure if you’d been checking… I believe there is going to be an Anita memorial of sorts at the blogger meetup tomorrow night. So, wanted to let you know… //t

Joe has broad software engineering development and management experience, from startups to large companies. Joe works on projects ranging from mobile to multi-cloud distributed systems, has set up and led engineering teams and processes, as well as managing and running services. Joe also contributes and collaborates with a wide variety of open source projects, and writes online at https://rhonabwy.com/.