Editing Software transactional memory (section)

== Implementation issues ==
One problem with implementing software transactional memory with optimistic reading is that it is possible for an incomplete transaction to read inconsistent state (that is, to read a mixture of old and new values written by another transaction). Such a transaction is doomed to abort if it ever tries to commit, so this does not violate the consistency condition enforced by the transactional system, but it is possible for this "temporary" inconsistent state to cause a transaction to trigger a fatal exceptional condition such as a segmentation fault or even enter an endless loop, as in the following contrived example from Figure 4 of "Language Support for Lightweight Transactions":

{|style="width:100%;"
|
|width=58%|
<!--The actual table starts here. The outer invisible table is a quirk to have IE render the table centered without centering the table contents.-->
{|class="wikitable" border="1"
|width=50%|
 '''atomic''' {
     if (x != y)
         while (true) { 
         }
 }
|width=50%|
 '''atomic''' {
     x++;
     y++;
 }
|- style="background:#C0C0C0; align:left"
!{{center|Transaction A}}
!{{center|Transaction B}}
|}
<!--The table ends here-->
|
|}

Provided ''x''=''y'' initially, neither transaction above alters this invariant, but it is possible that transaction A will read ''x'' after transaction B updates it but read ''y'' before transaction B updates it, causing it to enter an infinite loop. The usual strategy for dealing with this is to intercept any fatal exceptions and abort any transaction that is not valid.

One way to deal with these issues is to detect transactions that execute illegal operations or fail to terminate and abort them cleanly; another approach is the [[#Transactional locking|transactional locking]] scheme.