STM vs. locks

Skip to first unread message

Raoul Duke

May 13, 2008, 1:04:27 PM5/13/08

I don't actually really like shared-mutable-state-concurrency, but I
also am not yet a complete convert to STM, and would like to learn
about your take on it all. One main advantage (there aren't many) of
locks over STM is that you can pretty easily profile to see what locks
are hotly contended, and refactor to break things up. But if you get a
performance killing transaction rollback, it is as far as I know
impossible to see why that happened, which means it is harder to
fix/optimize things.

Any experiences around such issues? Many thanks for any thoughts.


Rich Hickey

May 13, 2008, 1:42:14 PM5/13/08
to Clojure
I don't think accountability is an inherent property of either
approach. The Clojure STM does know the ref that caused a transaction
rollback, but does nothing with that at present. It would be easy to
add a counter to each ref that would track its retry count. That would
give you a very accurate measure of contention, which is really about
the data and not the locks, e.g. if you had a lock governing access to
A, B and C that was hotly contended, you still wouldn't know which of
them was responsible, whereas the refs are related to the data itself.

I'll consider adding this, as it would be a useful metric.

Reply all
Reply to author
0 new messages