Could you give an example? A read-write conflict where the value has not changed? Or..?

I don’t see a visible read as a direct requirement; it is a means to a goal. In my case I use it for object recycling, retry, writeskew protection and for providing a transaction level read consistency. If object granularity is used, read tracking becomes less expensive (since less state needs to be tracked), and with a good transaction design you can come a long way (in the new betastm I use an array to store a binary search tree for reads.. so very low garbage production.. even the arrays are pooled). But.. tracking reads can be more expensive than not tracking them

It depends on the STM design and features needed, if it needed. I also have implemented a non read tracking transaction for the beta stm, but it will fail on conflicts even though there are no real conflicts because it has no means to revalidate its readset.

At an abstract level they would seem to be somewhat opposed – read tracking attempts to keep reads local and reduce the amount of accesses to the actual object, whilst visible reads require a “link” between the transaction’s copy of the read varible and the actual object (so that it can track writers).