QuickStudy: Transactional Memory

With the increasing use of multicore CPUs in computers, programmers have to learn new techniques for parallel processing. One very promising approach is transactional memory.

The primary problem for programmers is that multiple programming threads that are executed simultaneously by different processors must often access the same memory or stored data. It is difficult to determine in advance which thread will write its results first. If one thread changes data in memory, that may invalidate another thread's processing.

Thus, the system needs to make sure that the correct write operations take place at the proper time, without interference, disruption or undue degradation of performance.

To accomplish this, transactional memory runs code as "atomic blocks" inside a transaction, and all memory reads and writes are isolated until they are determined to be safe. Atomic here means that the code runs without interruption. When an atomic block completes, the system rechecks memory and looks for conflicts. Finding none, it executes the write operations, and these results become visible to the entire system.

If the system detects conflicts, however, it discards the transaction log and re-executes the block. When the contending threads are re-executed, they may proceed in a different order, thereby solving the conflict. While not exactly elegant, this solution seems to work well enough.

If an exception or error is somehow not handled inside the atomic block, all updates that block would make are automatically tossed away.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark