Transactions can provide scalability as long as …

Unlocking Concurrency

Unlike coarse-grained locking, transactions can provide scalability as long as the data-access patterns allow transactions to execute concurrently. The transaction system can provide good scalability in two ways:

  • It can allow concurrent read operations to the same variable. In a parallel program, it’s safe to allow two or more threads to read the same variable concurrently. Basic mutual exclusion locks don’t permit concurrent readers; to allow concurrent readers, the programmer has to use special reader-writer locks, increasing the program’s complexity.
  • It can allow concurrent read and write operations to different variables. In a parallel program, it’s safe to allow two or more threads to read and write disjoint variables concurrently. A programmer can explicitly code fine-grained disjoint access concurrency by associating different locks with different fine-grained data elements. This is usually a tedious and difficult task, however, and risks introducing bugs such as deadlocks and data races. Furthermore, as we show in a later example, fine-grained locking does not lend itself to modular software engineering practices: In general, a programmer can’t take software modules that use fine-grained locking and compose them together in a manner that safely allows concurrent access to disjoint data.

Transactions can be implemented in such a way that they allow both concurrent read accesses, as well as concurrent accesses to disjoint, fine-grained data elements (e.g., different objects or different array elements). Using transactions, the programmer gets these forms of concurrency without having to code them explicitly in the program.

“Power is performance”, John Hennessy

A Conversation with John Hennessy and David Patterson

KUNLE OLUKOTUN: There are many other issues beyond performance that could impact computer architecture. What ideas are there in the architecture realm, and what sort of impact are these other nonperformance metrics going to have on computing?
JOHN HENNESSY: Well, power is easy. Power is performance. Completely interchangeable. How do you achieve a level of improved efficiency in the amount of power you use? If I can improve performance per watt, I can add more power and be assured of getting more performance.
DAVID PATTERSON: It’s something that has been ignored so far, at least in the data center.
JOHN HENNESSY: I agree with that. What happened is we convinced ourselves that we were on a long-term road with respect to ILP that didn’t have a conceivable end, ignoring the fact that with every step on the road we were achieving lower levels of efficiency and hence bringing the end of that road closer and closer. Clearly, issues of reliability matter a lot, but as the work at Berkeley and other places has shown, it’s a far more complicated metric than just looking at a simple notion of processor reliability.
DAVID PATTERSON: Yes, I guess what you’re saying is, performance per watt is still a quantitative and benchmarkable goal.