On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote: > + // Honor an abort from abortTransaction. > + else if (htm_abort_is_cancel(ret)) > + return a_abortTransaction | a_restoreLiveVariables;
The problem is that we cannot reliably detect whether an abort with a certain abort reason code really means that we got canceled. A nested transaction is one example: how do we distinguish whether the nested or the outermost transaction were canceled?. Another example is transaction_pure or tm_wrapper code that might reuse the same abort reason for explicit aborts: we would like to allow malloc() calls in transactions, but if malloc uses transactions with explicit aborts, we might abort a transaction without a cause. It might be possible to avoid that by carefully specifying the rules for abort reasons, which of those can be used in nested transactions, and so on. But I'm not aware of any specification like that, and it seems to likely be a pretty fragile approach. Thus, there are two options for how to handle transactions that may abort: Either execute them transactionally the first time, and do an explicit HTM abort on transaction_cancel that tells libitm not not retry as HW transaction, or execute such transactions always as SW transactions. Which of these two options is better depends on how frequently transaction_cancel would actually be called. If it's infrequent, then trying to run as HW transactions might be better. Torvald
