1 / 8

Defining Strong Semantics in Programming Languages for Transactional Memory Systems

This document emphasizes the need to develop strong semantics for programming languages rather than focusing solely on transactional memory (TM) implementations. It argues for the definition of a visible programmer interface that abstracts away internal mechanisms of TM while ensuring features like atomicity, strong isolation, and race-free execution. The text reviews various implementations of atomic blocks, outlining how semantics impact multi-threaded execution and provide guidelines for effective memory handling and concurrency control, thereby enhancing performance and programmer experience.

udell
Télécharger la présentation

Defining Strong Semantics in Programming Languages for Transactional Memory Systems

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. We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

  2. The main argument Threads, atomic blocks, retry, OrElse Program Language implementation We should focus on defining this programmer-visible interface, rather than the internal interface used by the language implementation StartTx, CommitTx, ReadTx, WriteTx TM Read, Write, CAS H/W

  3. An analogy Program Garbage collected“infinite” memory Language implementation Low-level, broad, platform-specific API, no canonical def. GC H/W

  4. How: strong semantics for race-free programs 1 2 3 4 5 Strong semantics: simple interleaved model of multi-threaded execution T Thread 4 in an atomic block Data race: concurrent accesses to the same location, at least one a write Write(x) Write(x) Race-free: no data races (under strong semantics)

  5. Implementation 1: “classical” atomic blocks on TM Threads, atomic blocks, retry, OrElse Program Simple transformation Language implementation Lazy update, opacity,ordering guarantees... Strong TM H/W

  6. Implementation 2: very weak TM Threads, atomic blocks, retry, OrElse • No: • Guarantee that reads see a consistent view of memory • Guarantee that reads/writes don’t “spill over” to adjacent memory • Detection of tx/non-tx conflicts • Publication/privatization safety • Yes: • Strict serializability in a tx-only workload Program Language implementation Program analyses StartTx, CommitTx, ValidateTx, ReadTx(addr)->val, WriteTx(addr, val) Isolation of tx via MMU Very weak STM GC support Sandboxing for zombies H/W

  7. Implementation 3: lock inference Threads, atomic blocks, retry, OrElse Program Lock inference analysis Language implementation Locks Lock, unlock H/W

  8. Define semantics for languages, not for TM • We should focus on the interface between the language and the programmer • Define it without talking about tx • Permit a range of tx and non-tx implementations • In a high-perf implementation, it is hard to cleanly separate the TM from other components • Interface is likely to be broad, platform-specific, and may appear weaker than the language constructs

More Related