Multiverse 0.2 release nearing completion

Multiverse is a Java based STM implementation and the 0.2 version is nearing completion and I hope to finish it before 1 July. The 0.2 version is going to be a very usable implementation, unlike the 0.1 release, where most configuration can be done by placing some annotations. For more information about annotation based configuration, see the following tutorial.

Goal for this release

The goal of this release it to make Multiverse really easy to use, so that users don’t get scared (there is enough time for that) and let them realise that Software Transactional Memory can lead to a complete change in the way they write concurrent systems.

Todo and future plans

To see what needs to be done, check the following page. If you want to see what can be expected in the future, check the backlog. In the next release improving performance and scalability, and support for writing efficient STM data-structures, are going to be the most important goals.

Moving to Codehaus

I hope to move Multiverse to Codehaus as soon as the proposal is accepted. Google code is nice, but Codehaus has better Java facilities (continuous integration server, Licenses for Java tooling etc).

Multiverse needs a community

Multiverse is a Java based Software Transactional Memory implementation I have worked on for the last half year and I made a lot of progress and gained a lot of new insights. But there is too much to do for me alone and I would really like have some people on the project to learn from/teach things to/have fun with. So if you are interested in joining the community, have experience with concurrency control/instrumentation or would like to know a hell of a lot more about it, please send an email to alarmnummer at gmail.com.

The Springforum has lost its pazzaz

I have been reading and posting on the Spring forum since before it became mainstream, to be specific I joined on 22 November 2004. And under the name ‘Alarmnummer’ I have placed more than 1000 posts (in most cases answers to questions).

But the quality of the forum has dropped dramatically. Perhaps it is caused by:

1. Spring becoming yet another bloated environment
2. closed design by Spring-team and not the community
3. Spring getting too commercial

Thereby loosing touch with the community and especially with smart early adaptors.

Most questions I see on the forum are not about design any more, but in a lot of cases RTFM (Read the Fucking Manual) or UTFS (Use the Fucking Search) and not fun to answer at all.

Some STM Thoughts part II

In my spare time I have been working onMultiverse; to be specific on the instrumentation of POJO’s. A crude initial version is working and dropping the manual instrumentation of classes is a dream come true. But there is a lot left to do:

1. overcoming current instrumentation limitations like dealing with statics, inner classes, private and final fields.
   
2. optimisations like unmanaged reads to prevent unnecessary transaction overload. This could be done by escape analysis in the future, but I have to settle for annotations for now. Another optimisation is making final objects completely free to work with, so no extra STM caused CPU or memory usage. At the moment the STM doesn’t see the difference, so it tries to manage them and this causes the unnecessary usage.

Some thoughts about making the stm distributed:

1. With clock based STM’s, the maximum transaction speed is limited to the the maximum speed the clock run with. Because the read and write of this shared clock needs to be done atomically over the network. If the network action alone takes 1 ms the maximum number of transactions are 1000 per second. The same can be concluded if you apply ,Amdalah’s Law if you see network communication as sequential fractions that limit the maximum speed up. I guess it is also time to have a more thorough look at the work of Leslie Lamport.
2. The big difference is that distributed systems and non distributed systems is that the former is a lot less reliable, and this means that a STM implementation needs to deal with failure of notification. This could complicate matters like performance and the holy grail of software design: simplicity.