we should define semantics for languages, not for tm tim harris (msr cambridge)

8
We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

Post on 19-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

We should define semantics for languages, not for TM

Tim Harris (MSR Cambridge)

Page 2: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

The main argument

Language implementation

ProgramThreads,atomic blocks,retry, OrElse

TM

StartTx,CommitTx,ReadTx, WriteTx

H/W

Read, Write, CAS

We should focus on defining this programmer-visible interface, rather than the internal interface used by the language implementation

Page 3: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

An analogy

Language implementation

Program Garbage collected“infinite” memory

GC

Low-level, broad,platform-specific API,no canonical def.

H/W

Page 4: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

How: strong semantics for race-free programs

Strong semantics: simple interleaved model of multi-threaded execution

T

1 2 3 4 5

Thread 4 in an atomic block

Data race: concurrent accesses to the same location, at least one a write

Race-free: no data races (under strong semantics)

Write(x)

Write(x)

Page 5: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

Implementation 1: “classical” atomic blocks on TM

Language implementation

ProgramThreads,atomic blocks,retry, OrElse

Strong TM

Simple transformation

Lazy update, opacity,ordering guarantees...

H/W

Page 6: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

Language implementation

ProgramThreads,atomic blocks,retry, OrElse

StartTx, CommitTx,ValidateTx,ReadTx(addr)->val,WriteTx(addr, val)

Implementation 2: very weak TM

Very weak STM

• 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

Sandboxing for

zombies

Isolation of tx via MMU

Program analyses

GC support

H/W

Page 7: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

Implementation 3: lock inference

Language implementation

ProgramThreads,atomic blocks,retry, OrElse

LocksLock, unlock

Lock inference analysis

H/W

Page 8: We should define semantics for languages, not for TM Tim Harris (MSR Cambridge)

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