A Peek into the Future: Transactional Memory - Transactional memory
(Page 3 of 4 )
Transactional memory is believed to be the synchronization scheme of the future. First, it is much harder to get a deadlock with transactional memory (even though it is still possible), and second and most importantly, it doesn't suffer from the granularity problem described above. In other words, if two threads are accessing the same data structure, but are accessing different portions of it, the transactional memory scheme will let them proceed in parallel without any overhead. Intervention is needed only when two threads try to access the same portion of a data structure.
How will the programs look?
Transactional memory doesn't use locks or tokens or anything. It is based on the concept of a transaction. This can be described as an all-or-nothing approach. If your transaction can execute from beginning to end without conflicts, it will proceed and all the changes will be made. If any conflicts occur, it will roll back and all changes are cancelled.
Remember that array copying example? Let's see how it would look.
Subroutine Move(Array A, Array B)
Atomic
{
Read X from Array A
Write X to Array B
}
Very simple and neat, isn't it? What does this really do? Quite simply, it tells the compiler that you should try to read an element from array A and write it to array B. But, here is the catch, you should do this as one transaction. If at any time you detect any conflicts, roll back and assume that you have done nothing. For example, if you read from A without problems, and then detect a conflict while writing to B, you should abort the writing part, AND you should throw away the value X you read from A. This last part is very important, because some other thread could be trying to move an element into A. Since we have rolled back, we can no longer use the value we read from A. We should retry the whole transaction from the beginning. This way, we are always sure our data structures are consistent and having no conflicts.
As you can see, transactional memory systems are based on an optimistic approach. They let all the threads execute and only roll back when a conflict is detected. As you might guess, in real life, conflicts don't occur all that often! So, typically a transactional memory system should be able to outperform other schemes. It is also much simpler than locks and monitors. Finally, as mentioned before, it is not easy to get a transactional memory scheme to deadlock.
Next: So why is it not being used everywhere now? >>
More Development Cycles Articles
More By Mohamed Saad
