A Peek into the Future: Transactional Memory - So why is it not being used everywhere now?
(Page 4 of 4 )
This is a good question! Why isn't everyone out there using transactional memory systems already? To understand why this is the case, we need to look back at how transactional memory evolved.
When transactional memory was first implemented (way back in 1995), it was implemented as a pure software scheme. What this means is that it didn't require the help of hardware at all. This was attractive because the researchers who proposed the scheme didn't have enough resources to create their own hardware scheme too.
The problem with software transactional memory, though, is the cost of transaction management. A program has to be running all the time in the background, making sure that transactions are proceeding successfully! This program should be able to detect conflicts and roll back whenever a conflict happens. This costs much more than you might imagine. For instance, this program has to store the old values of all modified memory locations before the transaction commits. This is necessary in order to be able to roll back a transaction. This turns out to be very costly, and is not suitable for a small number of processors. To see any improvement we have to have a lot of processors.
So, software transactional memory is costly. Is this the end of the story? NO! Recently, researchers have became very interested in the idea of producing a hardware transactional memory system. What this means is that the cache memory chip itself will be responsible for enforcing integrity in the program. This means that nearly no overhead will be exerted on the CPU itself, and we certainly don't need additional programs running in the background to take care of conflicts and roll back. The hardware can take care of all this.
Having hardware transactional memory systems widely available is the dream of many researchers. Several research groups are now devoted to making this possible.
However, it is not easy. As you might imagine, having hardware transactional memory requires support from the OS (for example, to tell the hardware when the transaction is done), and requires support from the compiler (for example, in order to be able to understand the new "atomic" keyword, and generate the correct code for it).
Will we see hardware transactional memory systems any time soon? I certainly hope so. In the meantime, it is a good idea to get a better understanding of how the model works, and how to write programs for it, in order to be ready when it becomes a reality.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
