Applications have always striven for parallelism to take advantage of multiple CPUs. One of the things a program has to take care of in such an environment is data that is concurrently read or written by different threads or jobs. Traditionally this is done through Locks. A variety of locking techniques are used to synchronize data access, but generally problems encountered by programmers include complexity and overheads if the locks are too fine-grained, bottlenecks and lack of scaling if they are too coarse-grained, and concurrency issues introduced by the locks themselves. The problem will escalate as even single sockets now contain multiple cores, each of which can handle multiple threads.

Enter Transactional Memory. The concept is similar to transactions conducted on a database. Database transactions usually have ACID (Atomicity, Consistency, Isolation and Durability) properties that ensure correct processing and data integrity. Transferring money from your account to another, for instance, might involve several database operations but the latter are treated as one atomic transaction and either succeed altogether or fail altogether, thus ensuring no intermediate state. The same concept is being adapted for data operations in memory, in an effort to obviate the need for a programmer to worry about interactions between concurrent threads or operations.

Transactional Memory can be implemented in software or in hardware or as a hybrid of the two. In a Spotlight Article at Sun Labs, the research being carried out at the labs on transactional memory is detailed. Apart from research details, the article make note of the support in Rock for hardware transactional memory, the first ever implementation in a general purpose processor.

InternetNews.Com has an article discussing the announcement. Marc Tremblay discussed transactional memory support in his keynote at PODC last week.

Tags : Rock SPARC Concurrent Programming