Log in

No account? Create an account

Previous Entry | Next Entry

Transactional Memory Everywhere: Debugging

The usual debugging operations such as breakpoints work normally within lock-based critical sections and from RCU read-side critical sections. However, in initial transactional-memory hardware implementations an exception within a transaction will abort that transaction, which in turn means that breakpoints abort all enclosing transactions.

So how can transactions be debugged?


Sep. 20th, 2009 02:22 am (UTC)
And, of course, debugging by print{f,k} won't work well either, because you can't do IO in a transaction without fundamentally changing the nature of that transaction somehow. (Unless you cheat and create a non-transactional debugging-IO escape hatch, and even then you'll need to do some extra checking/printing to help you figure out if a transaction that just printed a message saying "doing foo" rolled back.)

- Josh
Sep. 20th, 2009 03:31 am (UTC)
Excellent point!
Debugging print{f,k} is indeed another good example of a debugging technique that works naturally with lock-based critical sections, but not so much with transactions.

As long as you aren't using (say) printk() to debug inside one of printk()'s critical sections. Of course, using printk() to debug printk() even outside of all of printk()'s critical sections is fraught with peril!