>suggests that Hardware Transaction Memory may not be the panacea we all >expect it to be, and in some cases may actually increase CPU
Of course it's true that if a transaction experiences too much contention and resorts to its fallback path, you have used more CPU than if you went directly to the fallback path. That is specifically why every use of non-constrained transactions ought to do analysis to determine if it is even theoretically beneficial. What I don't see mentioned in the article is zEC12's constrained transactions. By their very definition they need no fallback path. That is a huge benefit both in terms of complexity and development/test cost. >In PLO, the hardware locking occurs according to the lock word. You seem to be assuming that PLO implementation actually is truly locked according to the individual lock word. Maybe it is now. It definitely did not used to be. The machine would decide how to map the individually-specified lock word to (limited) hardware resources that were the true serialization mechanism. It was not necessarily one to one. >Transaction Memory sounds exciting but it's complex. IBM should put a >layer of abstraction on top with simple semantics. Maybe it's me, but I don't really find TBEGIN...TEND complex compared to other serializing techniques even when you factor in PPI while counting the number of attempts before taking the fallback path. The instructions within a transaction are typically less complex than the instructions you would need without a transaction, if you could even accomplish what you're trying to do outside of a transaction. For example, there is no need for CS, PLO. Just more straightforward "compare", "store", etc. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
