Project checkpoint

Situation Normal, All’s Fine and Unconcerning

Schedule

We are behind schedule. Our original schedule had us at a point where we would have implemented a whole bunch of cool features (e.g. task abort and restart) by now. We failed to account for our relative unfamiliarity with a new programming language.

An updated schedule can be found here.

Work done

We have implemented the STM primitives the NOrec paper talks about, exactly how it says to do them. The STM system described in the paper only handles objects that can be read/written as words. We’re trying to present a better interface to this by using Rust features such as the Into<usize> trait to allow users to use our STM implementation for more types (they do, however, have to provide the conversion to usize (which is Rust’s platform-dependent pointer-sized unsigned integer). However, since we’re both fairly unfamiliar with Rust, we haven’t gotten this to compile yet.

In addition, the library interface is somewhat ugly right now. For instance, our implementation of a transaction abort requires the user to wrap certain library functions with a try! macro; we feel it is suboptimal to foist this responsibility onto the user.

Goals and deliverables

We believe that we can work out these issues over the next few days and finish off deliverable number 1, which is of course the STM library itself. Then we’ll start writing benchmarks (e.g. hand-over-hand locking trees vs STM trees). We should still be on track to hit the original deliverables that we listed on the proposal.

It’s unlikely that we’ll have time to mess with pessimistic STM or have too pretty an abort interface for our STM library at this rate.

To summarise our goals for the project presentation deadline:

  1. An STM library
  2. A testing harness
  3. Benchmarks, written with our library, with another STM implementation, and without STM

Presentation plan

We have yet to decide what our presentation should look like. However, we will most likely aim to demonstrate the performance benefits of using our STM library to synchronize multithreaded access to shared data over using traditional locks. We also plan to log the performance of our library as we add changes and make progress along the way. The results will probably be presented in the form of graphs/charts.

Major concerns

We are still learning Rust. It has many interesting features such as concepts of borrowing and ownership that we have yet to fully grasp. Also, as we have not yet been able to get our library to compile, we do not know if there are any major correctness or efficiency issues that might necessitate a large redesign of our library.