1 / 14

Transactional Memory Coherence and Consistency

This presentation discusses Transactional Memory Coherence and Consistency (TCC), a model designed for transactional shared memory. TCC requires specialized hardware and relies on broadcast and snooping mechanisms, yet it is not infinitely scalable. The model implements Conditional Critical Regions (CCR) for atomic statements, utilizing hardware features like extra cache bits, write buffers, and commit control. Furthermore, it addresses performance challenges including load imbalances and high commit arbitration times while proposing approaches to optimize transaction sizes and manage dependencies effectively.

varian
Télécharger la présentation

Transactional Memory Coherence and Consistency

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Transactional Memory Coherence and Consistency Presented to CS258 on 4/28/08 by David McGrogan

  2. Review: Multiproc configurations • Message passing • Simple hardware • Tricky to program • Shared memory • Complex hardware • No implicit synchronization • Sometimes easier to program

  3. Something new: TCC Transactional memory Coherence and Consistency model • Provides transactional shared memory • Requires specialty hardware • Relies on broadcast and snooping • Not infinitely scalable

  4. Something new: TCC Transactional memory Coherence and Consistency model • Implements CCR (Conditional Critical Regions): atomic (condition) { statements; }

  5. TCC protocol • Writes in a transaction stored locally • System-wide commit arbitration • All writes broadcasted as a packet • Different commits cannot overlap • Transactions can be ordered via hardware-managed ‘phase numbers’

  6. TCC hardware • Extra cache bits • Write buffer • Commit control • Optional: Shadow registers Victim buffer

  7. TCC hardware • Cache bits • Read (can be multiple per line) • Modified • Renamed (multiple) – entire associated word/byte has been written, so future reads can’t cause violations

  8. TCC hardware • Write buffer • Hardware-based packet buffer • Lets processor do more important things • Commit control • Stores phase numbers for all other nodes • Reduces arbitration request traffic greatly

  9. Optional TCC hardware • Shadow registers • Copy core registers upon transaction start • Permits rollback • Can be done in software • Victim buffer • Holds flushed read/modified cache lines • If absent, must wait for and hold commit permission until transaction commits

  10. Errata • I/O • Input can only be accepted if rollback is impossible • Commit permission requested immediately • Hardware optimizations • Break up large transactions • Merge small transactions • Force forward progress by increasing phase

  11. Cache state size • Most benchmarks operate within 12 kB of read state and 8 kB of write state • Easily fits in the smallest of modern caches

  12. Performance (ideal) • Limited by sequential code, load imbalance, inter-transaction dependencies

  13. Performance Errata • More realistic simulations • Viability retained in most cases • Sometimes crippled by very high commit arbitration times (200 cycles) • Various optimizations had little effect • Double-buffering write buffer • Extra read bits (sub-line read records)

More Related