How is atomicity of transactions defined?  Basically you define atomicity with respect to other things.  Write transations are obviously atomic w.r.t other write transactions, but what about reads?  With single reads obviously you can't tell but what if you were traversing a linked list that had concurrent write updates being applied to it for example?  On such a traversal, would you see all or none of any write transaction, or would you see parts of write transactions depending on which nodes in the list got updated and where you were in the traversal when the updates happened?  Or are there read transactions as well?  So before you traverse through the list, you start a read transaction so you get a consistent version of the list.  And do you have retries on read transactions or do you use the memory management scheme to keep things consistent?

I had done some investigation is this area myself when I was looking on a couple of occasions at what it would take to make TDB (Trivial DataBase), which is used by Samba, lock-free using RCU for preemptive user threads (or something very much like it).  On the second occasion I got around to looking at the actual code and realized that TDB had transactions.   So I had to figure out how to do read lock-free transactions.  Ultimately, too much work was involved for not very well defined benefits.  But bascially when you do this kind of stuff (lock-free), you become aware of the importance of well defined semantics.