1 / 8

We should define semantics for languages , not for TM

We should define semantics for languages , not for TM. Tim Harris (MSR Cambridge). The main argument. Threads, atomic blocks, retry, OrElse. Program. Language implementation.

udell
Download Presentation

We should define semantics for languages , not for TM

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