thanks to both gpderetta and chrisseaton for their insightful replies. as i was looking for more sources of information, i stumbled upon this:
<a href="http:&#x2F;&#x2F;kukuruku.co&#x2F;hub&#x2F;cpp&#x2F;transactional-memory-history-and-development" rel="nofollow">http:&#x2F;&#x2F;kukuruku.co&#x2F;hub&#x2F;cpp&#x2F;transactional-memory-history-and-...</a>
where we see a large number of folks trying and eventually giving up on tm both in h&#x2F;w and s&#x2F;w implementations e.g. sun tried adding tm support to their sparc(rock)-v9 processor, but after oracle bought them, the project was shelved for “This processor had two astonishing features: it was incredibly low and consumed plenty of energy. It was so hot that they had to hang 12 inches of cooling fans so that processor wouldn’t overheat. It would have been insane to continue this project.”<p>to me at least, it seems that optimistic-reads with in-place pessimistic writes and automatic retries a.k.a weakly-atomic-update-in-place (raison d&#x27;être for tm) is the biggest torpedo in tm&#x27;s direction.<p>for example, assume we have :<p>---x---x---x---x---x---x---x---x---x<p><pre><code>   bool owning_obj = false;
   some_obj x = new some_obj();

   &#x2F;* txn-0 *&#x2F;
   atomic {
       owning_obj = true;
   }

   int z = x.some_value;
</code></pre>
---x---x---x---x---x---x---x---x---x<p><pre><code>   &#x2F;* txn-1 *&#x2F;
   atomic {
       if (!owning_obj)
           x.some_value = 12314;
   }
</code></pre>
---x---x---x---x---x---x---x---x---x<p>ok, so now we have a problem :), specifically : although txn-1 would rollback, because the value of owning_obj is changed, but it is too late. the other thread using x (txn-0) will see a constantly changing state. who knows what will happen next.<p>it might be possible to have some kind of RCU semantics here, where you wait for a quiescent state to be reached, but that would be pretty complicated.<p>may you please provide your comments ? it is all very educational :)