Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Future of Concurrency Theory Renaissance or Reformation? (Met dank aan Maurice Herlihy) Frits Vaandrager.

Similar presentations


Presentation on theme: "The Future of Concurrency Theory Renaissance or Reformation? (Met dank aan Maurice Herlihy) Frits Vaandrager."— Presentation transcript:

1 The Future of Concurrency Theory Renaissance or Reformation? (Met dank aan Maurice Herlihy) Frits Vaandrager

2 Intreedag 20082 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

3 Intreedag 20083 Moore’s Law Clock speed flattening sharply Transistor count still rising

4 Intreedag 20084 4 Still on some of your desktops: The Uniprocesor memory cpu

5 Intreedag 20085 5 In the Enterprise: The Shared Memory Multiprocessor (SMP) cache Bus shared memory cache

6 Intreedag 20086 6 Your New Desktop: The Multicore Processor (CMP) cache Bus shared memory cache All on the same chip Sun T2000 Niagara

7 Intreedag 20087 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.... “

8 Intreedag 20088 Renaissance? World (re)discovers Concurrency Theory achievements This has already happened (sort-of) World learns of concurrency results

9 Intreedag 20089 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

10 Intreedag 200810 In Classic Antiquity Time cured software bloat Double your path length? –Wait 6 months, until –Processor speed catches up

11 Intreedag 200811 Multiprocessor companies failed in 80s Outstripped by sequential processors Field respected, but not taken seriously Parallelism Didn’t Matter

12 Intreedag 200812 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

13 Intreedag 200813 What Keeps Microsoft and Intel awake at Night? If more cores does not deliver more value … Then why upgrade? ?

14 Intreedag 200814 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

15 Intreedag 200815 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 !

16 Intreedag 200816 With Sudden Relevance Comes Great Responsibility Many challenges involve –Concurrent algorithms –Data structures –Formal models –Complexity & lower bounds, –…–… Stuff we’re good at.

17 Intreedag 200817 Concurrent Programming Today

18 Intreedag 200818 Coarse-Grained Locking Easily made correct … But not scalable.

19 Intreedag 200819 Fine-Grained Locking Here comes trouble …

20 Intreedag 200820 Locks are not Robust If a thread holding a lock is delayed … No one else can make progress

21 Intreedag 200821

22 Intreedag 200822 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)

23 Intreedag 200823 Sadistic Homework enq(x) deq(y) FIFO queue No interference if ends “far enough” apart

24 Intreedag 200824 Sadistic Homework enq(x) deq(y) FIFO queue Interference OK if ends “close enough” together

25 Intreedag 200825 You Try It … One lock? –Too Conservative Locks at each end? –Deadlock, too complicated, etc Publishable result? –Once, maybe still?

26 Intreedag 200826 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.”

27 Intreedag 200827 Don’t be Shy Marc Schoolderman (first year CS student from Nijmegen) discovered bugs in published “solution” of Downey using a model checker

28 Intreedag 200828 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

29 Intreedag 200829 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

30 Intreedag 200830 Public void LeftEnq(item x) { atomic { Qnode q = new Qnode(x); q.next = this.tail; this.tail.next = q; } Sadistic Homework Revisited (1)

31 Intreedag 200831 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

32 Intreedag 200832 Warning Not always this simple –Conditional waits –Enhanced concurrency –Complex patterns But often it is –Works for sadistic homework

33 Intreedag 200833 Public void Transfer(Queue q1, q2) { atomic { T x = q1.deq(); q2.enq(x); } Composition (1) Trivial or what?

34 Intreedag 200834 Not All Skittles and Beer Algorithmic choices –Lower bounds –Better algorithms Language design Semantic issues –Like memory models –Atomicity checking

35 Intreedag 200835 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

36 Intreedag 200836 Strong vs Weak Isolation How do transactional & non-transactional threads synchronize? Similar to memory- model theory? Efficient algorithms?

37 Intreedag 200837 Single Global Lock Semantics? Transactions act as if it acquires SGL Good: –Intuitively appealing Bad: –What about aborted transactions? –Expensive? Need better models

38 Intreedag 200838 Formal Models of Performance Asynchrony

39 Intreedag 200839 Formal Models of Performance Asynchrony Multi-level Memory

40 Intreedag 200840 Formal Models of Performance Asynchrony Multi-level Memory Contention

41 Intreedag 200841 Formal Verification Concurrent algorithms are hard Need routine verification of real algorithms Model checking? Theorem proving? Probably both

42 Intreedag 200842 An Insurmountable Opportunity! Multicore forces us to rethink almost everything

43 Intreedag 200843 An Insurmountable Opportunity! Multicore forces us to rethink almost everything The fate of CS as a vibrant field depends on our success

44 Intreedag 200844 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

45 Intreedag 200845 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?


Download ppt "The Future of Concurrency Theory Renaissance or Reformation? (Met dank aan Maurice Herlihy) Frits Vaandrager."

Similar presentations


Ads by Google