Transactional memory for GCC 4.7.0

Features for failure atomicity (cancel, cancel-outer, cancel-and-throw) require atomic transactions. A transaction marked as "outer" therefore must always be an atomic transaction. Nonetheless, failure atomicity is like an add-on, you don't have to use it or care about it if you don't need it (see the section at the end of the specification that explains the dependencies between features).

The reason why we restrict normal cancel to lexical scope and cancel-outer to specially marked transactions is that we do not want programmers guessing whether a call hidden somewhere in a larger transaction could cancel the transaction or not. Normal transactions give you exactly-once semantics, whereas transactions that can be canceled are at-most-once (while still being atomic of course).

If throw would cancel a transaction by default, we would change the semantics of existing code. So no, we don't want that.

"Retry provision": I'm not exactly sure which semantics you are referring to here (like what's been proposed by Harris et al.?). Note that you cannot busy-wait for some condition to change in a transaction, simply because it's supposed to be atomic and isolated.

Finally, we just don't know how people will use transactions. Sure, you often want to keep synchronizing regions small, but that will not be a good choice for some programmers or programs. So, from a specification perspective, "simplifying the whole thing" would mean to assume a given narrow use case and prevent other uses.

The current specification does not prevent you from using transactions in the simple form you mentioned, so if you want that, you can have it. Here's a simple recipe: Only use __transaction_atomic, and never call any functions in a different compilation unit. And that's it, no further annotations necessary (the specification allows compilers to automatically infer whether a function is transaction_safe, and this is what GCC does too).