DSTM Bug Yesterday

I need to write this down before lunch.

James found a bug in my DSTM implementation yesterday. As I mentioned earlier, to memory manage the trasnactions, each transaction has a counter of the number of objects poiting to it.

Now as each transaction aquires an object, this counter is incremented. While as each transaction has an object dissassociated with it, the counter is decremented.

Now this counter can only be incremented by one thread (since only one thread can assocaite objects with a transaction). What I didn't think of is that more than one thread can actually decrement the counter. This is how that could happen:

Let's say a transaction has more than one object assocaited with it, then commits. Now two different new transactions running under different threads could associate different objects that were assocaited with the old transaction, thus decrementing the counter simultaniously. If the decrement isn't atomic, this could cause problems.

This is easily solved by either using an atomic decrement instruction or an atomic compare and swap. (or maybe SLE)