In 1993, Maurice Herlihy and a colleague published a paper on transactional memory — a new, clever tactic in computing to deal with handling shared revisions to information seamlessly and concurrently. Few noticed.
Nearly 20 years later, transactional memory is an idea that’s now the rage in hardware computing, and Herlihy, computer science professor at Brown University, has morphed into a prophet of sorts, a computing pioneer who was far ahead of his time. Intel recently announced that transactional memory will be included in its mainstream “Haswell” hardware architecture by next year. IBM has adopted transactional memory in the Blue Gene/Q supercomputer. The original paper by Herlihy and Eliot Moss has been cited more than 1,300 times.
“At the time, we thought (transactional memory) was really cool, but it was hard to attract attention to it — it was this specialized corner,” Herlihy said. “We weren’t necessarily geniuses ahead of our time, because it solved a problem that didn’t exist yet.”
The problem, as Herlihy explained it, was that core processors — the engines that program instructions — were changing in fundamental ways. As computers, along with their components got smaller and smaller, a single processor was unable to scale in size and still handle the data-lifting requirements. But multiple processors presented their own challenges: how to coordinate information sharing and revisions, in parallel and in real time.
At the time, processing was ruled by a series of locks, a kingdom where one thread held a key to the lock at any one time. This ensured that no other thread could pick the lock — modify a shared resource at the same time — but it also dragged down the transactional operating speed and efficiency.
“The trick was figuring out how to do this in a more efficient way,” Herlihy said.
Herlihy, who had just joined the Brown faculty from a Cambridge, Mass., company called Digital Equipment Corp., and Moss, a computer scientist at the University of Massachusetts–Amherst, sought to design a system that would be more flexible. Their solution was simple and elegant. The pair dreamed up a system of requests and permissions, whereby operations are begun and logged in, but wholesale changes, or transactions, are not made before the system checks to be sure no other thread has suggested changes to the pending transaction as well. If no other changes have been requested, the transaction is consummated; if there is another change request, the transaction is aborted, and the threads start anew.
“We always said that parallel machines with more than one processor were going to be important someday, but nobody knew when it would happen,” Herlihy said. “We were surprised that it did happen as we thought it would.”
Transactional memory has been lighting up the computing technology chattersphere in recent months. On the well-regarded Ars Technica site, a writer called transactional memory “a promising technique designed to make the creation of multithreaded programs easier.” Intel advertises its form of transactional memory as “hardware (that) can determine dynamically whether threads need to serialize through lock-protected critical sections, and perform serialization only when required. This lets the processor expose and exploit concurrency that would otherwise be hidden due to dynamically unnecessary synchronization.”
Although it was a long time coming, the buzz around transactional memory is “very satisfying,” Herlihy said, modestly. “This shows the importance of long-range research.”