The Future of Concurrency Theory Renaissance or Reformation?
description
Transcript of The Future of Concurrency Theory Renaissance or Reformation?
![Page 1: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/1.jpg)
The Future of Concurrency Theory
Renaissance or Reformation?
(Met dank aan Maurice Herlihy)
Frits Vaandrager
![Page 2: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/2.jpg)
Intreedag 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
![Page 3: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/3.jpg)
Intreedag 2008 3
Moore’s Law
Clock speed
flattening sharply
Transistor count still
rising
![Page 4: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/4.jpg)
Intreedag 2008 44
Still on some of your desktops: The Uniprocesor
memory
cpu
![Page 5: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/5.jpg)
Intreedag 2008 55
In the Enterprise: The Shared Memory
Multiprocessor(SMP)
cache
BusBus
shared memory
cachecache
![Page 6: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/6.jpg)
Intreedag 2008 66
Your New Desktop: The Multicore Processor
(CMP)
cache
BusBus
shared memory
cachecacheAll on the same chip
Sun T2000Niagara
![Page 7: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/7.jpg)
Intreedag 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. ... “
![Page 8: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/8.jpg)
Intreedag 2008 8
Renaissance?• World (re)discovers
Concurrency Theory achievements
• This has already happened (sort-of)
World learns of concurrency results
![Page 9: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/9.jpg)
Intreedag 2008 9
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
![Page 10: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/10.jpg)
Intreedag 2008 10
In Classic Antiquity• Time cured software
bloat• Double your path
length?– Wait 6 months, until– Processor speed
catches up
![Page 11: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/11.jpg)
Intreedag 2008 11
• Multiprocessor companies failed in 80s
• Outstripped by sequential processors
• Field respected, but not taken seriously
Parallelism Didn’t Matter
![Page 12: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/12.jpg)
Intreedag 2008 12
The Old Order Lies in Ruins
• Six months means more cores, same clock speed
• Must exploit more parallelism
• No one really knows how to do this
![Page 13: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/13.jpg)
Intreedag 2008 13
What Keeps Microsoft and Intel awake at Night?
• If more cores does not deliver more value …
• Then why upgrade?
?
![Page 14: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/14.jpg)
Intreedag 2008 14
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
![Page 15: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/15.jpg)
Intreedag 2008 15
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
!
![Page 16: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/16.jpg)
Intreedag 2008 16
With Sudden Relevance Comes Great Responsibility
• Many challenges involve– Concurrent algorithms– Data structures– Formal models– Complexity & lower bounds,– …
• Stuff we’re good at.
![Page 17: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/17.jpg)
Intreedag 2008 17
Concurrent Programming Today
![Page 18: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/18.jpg)
Intreedag 2008 18
Coarse-Grained Locking
Easily made correct …But not scalable.
![Page 19: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/19.jpg)
Intreedag 2008 19
Fine-Grained Locking
Here comes trouble …
![Page 20: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/20.jpg)
Intreedag 2008 20
Locks are not Robust
If a thread holdinga lock is delayed
…
No one else can make progress
![Page 21: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/21.jpg)
Intreedag 2008 21
![Page 22: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/22.jpg)
Intreedag 2008 22
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)
![Page 23: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/23.jpg)
Intreedag 2008 23
Sadistic Homework
enq(x) deq(y)FIFO queue
No interference if ends “far
enough” apart
![Page 24: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/24.jpg)
Intreedag 2008 24
Sadistic Homework
enq(x) deq(y)FIFO queue
Interference OK if ends “close
enough” together
![Page 25: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/25.jpg)
Intreedag 2008 25
You Try It …
• One lock?– Too Conservative
• Locks at each end?– Deadlock, too
complicated, etc
• Publishable result?– Once, maybe still?
![Page 26: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/26.jpg)
Intreedag 2008 26
Downey’s Room Party Problem
“A dean of students should keep order in the students' house. In order to do this, he can enter a room with too many students (in order to break up a too large party) or he can enter an empty room to conduct a search. Otherwise, the dean may not enter a room. If the dean is in a room, no additional students may enter, but students may leave. In that case, the dean has to stay until all students have left.There is only one dean, and no limitation on the number of students in one room.”
![Page 27: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/27.jpg)
Intreedag 2008 27
Don’t be ShyMarc Schoolderman (first year CS student from Nijmegen) discovered bugs in published “solution” of Downey using a model checker
![Page 28: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/28.jpg)
Intreedag 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
![Page 29: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/29.jpg)
Intreedag 2008 2929
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
![Page 30: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/30.jpg)
Intreedag 2008 3030
Public void LeftEnq(item x) { atomic { Qnode q = new Qnode(x); q.next = this.tail; this.tail.next = q; }}
Sadistic Homework Revisited
(1)
![Page 31: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/31.jpg)
Intreedag 2008 3131
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
![Page 32: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/32.jpg)
Intreedag 2008 3232
Warning• Not always this
simple– Conditional waits– Enhanced concurrency– Complex patterns
• But often it is– Works for sadistic
homework
![Page 33: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/33.jpg)
Intreedag 2008 3333
Public void Transfer(Queue<T> q1, q2){ atomic { T x = q1.deq(); q2.enq(x); }}
Composition
(1)
Trivial or what?
![Page 34: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/34.jpg)
Intreedag 2008 34
Not All Skittles and Beer• Algorithmic choices
– Lower bounds– Better algorithms
• Language design• Semantic issues
– Like memory models
– Atomicity checking
![Page 35: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/35.jpg)
Intreedag 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
![Page 36: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/36.jpg)
Intreedag 2008 36
Strong vs Weak Isolation
• How do transactional & non-transactional threads synchronize?
• Similar to memory-model theory?
• Efficient algorithms?
![Page 37: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/37.jpg)
Intreedag 2008 37
Single Global Lock Semantics?
• Transactions act as if it acquires SGL
• Good:– Intuitively appealing
• Bad:– What about aborted
transactions?– Expensive?
• Need better models
![Page 38: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/38.jpg)
Intreedag 2008 38
Formal Models of Performance
• Asynchrony
![Page 39: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/39.jpg)
Intreedag 2008 39
Formal Models of Performance
• Asynchrony• Multi-level
Memory
![Page 40: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/40.jpg)
Intreedag 2008 40
Formal Models of Performance
• Asynchrony• Multi-level
Memory• Contention
![Page 41: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/41.jpg)
Intreedag 2008 41
Formal Verification• Concurrent
algorithms are hard
• Need routine verification of real algorithms
• Model checking?• Theorem proving?• Probably both
![Page 42: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/42.jpg)
Intreedag 2008 42
An Insurmountable Opportunity!
• Multicore forces us to rethink almost everything
![Page 43: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/43.jpg)
Intreedag 2008 43
An Insurmountable Opportunity!
• Multicore forces us to rethink almost everything
• The fate of CS as a vibrant field depends on our success
![Page 44: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/44.jpg)
Intreedag 2008 44
An Insurmountable Opportunity!
• Multicore forces us to rethink almost everything
• The fate of CS as a vibrant field depends on our success
• Concurrency theory has unique insights & advantages
![Page 45: The Future of Concurrency Theory Renaissance or Reformation?](https://reader035.fdocuments.net/reader035/viewer/2022062323/56815747550346895dc4e93c/html5/thumbnails/45.jpg)
Intreedag 2008 45
An Insurmountable Opportunity!
• Multicore forces us to rethink almost everything
• The fate of CS as a vibrant field depends on our success
• Concurrency theory has unique insights & advantages
• Are we equal to the task?