The Future of Distributed Computing

Renaissance or Reformation?

Maurice HerlihyBrown University

PODC 2008 2

Le Quatorze Juillet

SAN FRANCISCO, May 7. 2004 - Intel said on Friday that it was scrapping its development of two microprocessors, a move that is a shift in the company's business strategy….

New York Times

PODC 2008 3

Moore’s Law

(hat tip: Simon Peyton-Jones)

Clock speed

flattening sharply

Transistor count still

rising

PODC 2008 4Art of Multiprocessor Programming 4

Still on some of your desktops: The Uniprocesor

memory

cpu

PODC 2008 5Art of Multiprocessor Programming 5

In the Enterprise: The Shared Memory

Multiprocessor(SMP)

cache

BusBus

shared memory

cachecache

PODC 2008 6Art of Multiprocessor Programming 6

Your New Desktop: The Multicore Processor

(CMP)

cache

BusBus

shared memory

cachecacheAll on the same chip

Sun T2000Niagara

PODC 2008 7

Multicores are Here

• “Learn how the multi-core processor architecture plays a central role in Intel's platform approach. ….”

• “AMD is leading the industry to multi-core technology for the x86 based computing market …”

• “Sun's multicore strategy centers around multi-threaded software. ... “

PODC 2008 8

Why should we care?

• First time ever,– PODC research

relevant to Real World™

• First time ever,– Real World™

relevant to PODC

Plato vs Aristotle

PODC 2008 9

Renaissance?

• World (re)discovers PODC community achievements

• This has already happened (sort-of)

World learns of PODC results

PODC 2008 10

Reformation?

• Can we respond to the Real World’s challenges?

• Are we working on problems that matter?

• Can we recognize what’s going to be important?Bonfire of the Vanities

PODC 2008 11

In Classic Antiquity

• Time cured software bloat

• Double your path length?– Wait 6 months, until– Processor speed

catches up

PODC 2008 12

• Multiprocessor companies failed in 80s

• Outstripped by sequential processors

• Field respected, but not taken seriously

Parallelism Didn’t Matter

PODC 2008 13

The Old Order Lies in Ruins

• Six months means more cores, same clock speed

• Must exploit more paralellism

• No one really knows how to do this

PODC 2008 14

What Keeps Microsoft and Intel awake at Night?

• If more cores does not deliver more value …

• Then why upgrade?

?

PODC 2008 15

Washing Machine Science?

• Computers could become like washing machines

• You don’t trade it in every 2 years for a cooler model

• You keep it until it breaks.

PODC 2008 16

No Cores Please, we’re Theorists!

• Computer Science is driven by Moore’s law

• Each year we can do things we couldn’t do last year

• Means funding, students, excitement !

PODC 2008 17

With Sudden Relevance Comes Great Responsibility

• Many challenges involve– concurrent algorithms– Data structures– formal models– complexity & lower bounds,– …

• Stuff we’re good at.

PODC 2008 18

Disclaimer

• What follows are my Opinions (mine, mine, mine!)

– And prejudices

• Targeted to people– New in the field

• No offence intended– In most cases.

PODC 2008 19

Concurrent Programming Today

PODC 2008 20

Coarse-Grained Locking

Easily made correct …But not scalable.

PODC 2008 21

Fine-Grained Locking

Here comes trouble …

PODC 2008 22

Locks are not Robust

If a thread holdinga lock is delayed

…

No one else can make progress

PODC 2008 23

Locking Relies on Conventions

• Relation between– Lock bit and object bits– Exists only in programmer’s mind

/* * When a locked buffer is visible to the I/O layer * BH_Launder is set. This means before unlocking * we must clear BH_Launder,mb() on alpha and then * clear BH_Lock, so no reader can see BH_Launder set * on an unlocked buffer and then risk to deadlock. */

Actual comment from Linux

Kernel(hat tip: Bradley Kuszmaul)

PODC 2008 24

Sadistic Homework

enq(x) deq(y)FIFO queue

No interference if ends “far

enough” apart

PODC 2008 25

Sadistic Homework

enq(x) deq(y)FIFO queue

Interference OK if ends “close

enough” together

PODC 2008 26

You Try It …

• One lock?– Too Conservative

• Locks at each end?– Deadlock, too

complicated, etc

• Publishable result?– Once, maybe still?

PODC 2008 27

Locks do not compose

add(T1, item)

delete(T1, item)

add(T2, item) item item

Move from T1 to T2

Must lock T2

before deleting from T1

lock T2lock T2lock T1lock T1

lock T1lock T1

item

Exposing lock internals breaks abstraction

Hash Table Must lock T1

before adding item

PODC 2008 28

The Transactional Manifesto

• What we do now is inadequate to meet the multicore challenge

• Research Agenda– Replace locking with a transactional API – Design languages to support this model– Implement the run-time to be fast

enough

PODC 2008 29© 2006 Herlihy & Shavit 29

Public void enq(item x) { Qnode q = new Qnode(x); q.next = this.tail; this.tail.next = q;}

Sadistic Homework Revisited

(1)

Write sequential Code

PODC 2008 30© 2006 Herlihy & Shavit 30

Public void LeftEnq(item x) { atomic { Qnode q = new Qnode(x); q.next = this.tail; this.tail.next = q; }}

Sadistic Homework Revisited

(1)

PODC 2008 31© 2006 Herlihy & Shavit 31

Public void LeftEnq(item x) { atomic { Qnode q = new Qnode(x); q.next = this.tail; this.tail.next = q; }}

Sadistic Homework Revisited

(1)

Enclose in atomic block

PODC 2008 32© 2006 Herlihy & Shavit 32

Warning• Not always this

simple– Conditional waits– Enhanced concurrency– Complex patterns

• But often it is– Works for sadistic

homework

PODC 2008 33© 2006 Herlihy & Shavit 33

Public void Transfer(Queue<T> q1, q2){ atomic { T x = q1.deq(); q2.enq(x); }}

Composition

(1)

Trivial or what?

PODC 2008 34

Not All Skittles and Beer

• Algorithmic choices– Lower bounds– Better algorithms

• Language design• Semantic issues

– Like memory models

– Atomicity checking

PODC 2008 35

Contention Management & Scheduling

• How to resolve conflicts?

• Who moves forward and who rolls back?

• Lots of empirical work but formal work in infancy

Judgment of Solomon

PODC 2008 36

I/O & System Calls?

• Some I/O revocable– Provide transaction-

safe libraries– Undoable file

system/DB calls

• Some not– Opening cash

drawer– Firing missile

PODC 2008 37

Privatization

• Transaction makes object inaccessible

• Works on it without synchronization

• Works with locks …• But not necessarily with

transactions …• Need algorithms and

models!

PODC 2008 38

Strong vs Weak Isolation

• How do transactional & non-transactional threads synchronize?

• Similar to memory-model theory?

• Efficient algorithms?

PODC 2008 39

Single Global Lock Semantics?

• Transactions act as if it acquires SGL

• Good:– Intuitively appealing

• Bad:– What about aborted

transactions?– Expensive?

• Need better models

PODC 2008 40

Progress, Performance Metrics and Lower Bounds

• Wait-free– Everyone makes

progress

• Lock-free– Someone makes

progress

• Obstruction-free– Solo threads make

progress

PODC 2008 41

Obstruction-Free?

• Experience suggests simpler, more efficient and easier to reason about

• But no real formal justification

• Progress conditions imperfectly understood

PODC 2008 42

Formal Models of Performance

• Asynchrony

PODC 2008 43

Formal Models of Performance

• Asynchrony• Multi-level

Memory

PODC 2008 44

Formal Models of Performance

• Asynchrony• Multi-level

Memory• Contention

PODC 2008 45

Formal Models of Performance

• Asynchrony• Multi-level

Memory• Contention• Memory Models

PODC 2008 46

Formal Models of Performance

• Asynchrony• Multi-level

Memory• Contention• Memory Models• Reads, writes,

CAS, TM and other stuff we may devise …

PODC 2008 47

Formal Verification

• Concurrent algorithms are hard

• Need routine verification of real algorithms

• Model checking?• Theorem proving?• Probably both

PODC 2008 48

PODC Victories

• Byzantine agreement

PODC 2008 49

PODC Victories

• Byzantine agreement• Paxos, group communication

PODC 2008 50

PODC Victories

• Byzantine agreement

• Paxos, group communication

• Replication algorithms

Photoshop™ replication algorithm

PODC 2008 51

PODC Victories

• Byzantine agreement

• Paxos, group communication

• Replication• Lock-free & wait-

free algorithms

PODC 2008 52

PODC Victories

• Byzantine agreement• Paxos, group

communication• Replication• Lock-free & wait-free

algorithms• Formalizing what needs

to to be formalized!

PODC 2008 53

An Insurmountable Opportunity!

(hat tip: Walt Kelley)

• Multicore forces us to rethink almost everything

PODC 2008 54

An Insurmountable Opportunity!

(hat tip: Walt Kelley)

• Multicore forces us to rethink almost everything

• The fate of CS as a vibrant field depends on our success

PODC 2008 55

An Insurmountable Opportunity!

(hat tip: Walt Kelley)

• Multicore forces us to rethink almost everything

• The fate of CS as a vibrant field depends on our success

• PODC community has unique insights & advantages

PODC 2008 56

An Insurmountable Opportunity!

(hat tip: Walt Kelley)

• Multicore forces us to rethink almost everything

• The fate of CS as a vibrant field depends on our success

• PODC community has unique insights & advantages

• Are we equal to the task?

PODC 2008 57

         This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.