STM’s and waitsets

September 21, 2008

At the moment I’m working on an experimental Software Transactional Memory (STM) implementation to gain better insight in this new but very promising way to deal with concurrency. One of the classic problems with waitsets, is that it is not possible to let a thread sleep on more than 1 waitset. If there are 2 blockingqueues for example (each instance has its own waitset) a taking thread can only block one of those blockingqueues. So when a taking-thread has blocked on one of the blockingqueues, it won’t wake up when an item is placed on the other.

With STM’s this issue can be solved. Each transaction logs which cells it has read from STM. And when a transaction can’t make progress, because the blockingqueues are empty, it signals that it should be retried as soon as an update on one of these addresses has happened.

The pseudo code for the transaction would be something like this:

if(queue1.isEmpty() && queue2.isEmpty())

In this case the internals of queue1 queue2 have been read from STM, so as soon as there is a change in these internals (an item is placed for example), the transaction is retried. Isn’t that cool?