Successfully reported this slideshow.
Your SlideShare is downloading. ×

Why Is Concurrent Programming Hard? And What Can We Do about It?

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 23 Ad

Why Is Concurrent Programming Hard? And What Can We Do about It?

Download to read offline

In short, I think, it is hard because on the one hand there is not a single concurrency abstraction that fits all problems, and on the other hand the various different abstractions are rarely designed to be used in combination with each other.

In short, I think, it is hard because on the one hand there is not a single concurrency abstraction that fits all problems, and on the other hand the various different abstractions are rarely designed to be used in combination with each other.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Why Is Concurrent Programming Hard? And What Can We Do about It? (20)

Advertisement

More from Stefan Marr (18)

Recently uploaded (20)

Advertisement

Why Is Concurrent Programming Hard? And What Can We Do about It?

  1. 1. Why Is Concurrent Programming Hard? And What Can We Do about It? Stefan Marr Zurich, September 10, 2015
  2. 2. 70 Years of Parallel Execution 2[U.S. Army Photo]
  3. 3. Perhaps >3,500 Books and >100,000 Papers? 3
  4. 4. … The Problem No Silver Bullet! Actors Transactional Memory Fork/Join Locks, Monitors, … 4 Data Flow
  5. 5. Actors 5 Actor A Actor B Data: No Shared Memory Parallelism: Structural, Between Actors
  6. 6. Actor Use Cases Hewitt/Agha Actors Communicating Event Loops 6 Finer Grained Parallel Entities Coarser Grained Subsystems User Interface Data Backend But you got to do parallel updates on graphs?
  7. 7. Transactional Memory 7 Thread A Thread B Isolated Area of A Isolated Area of B
  8. 8. Transactional Memory 8 Too much overhead? well structured data?Thread A Thread B Isolated Area of A Isolated Area of B
  9. 9. Fork/Join 9 Structured Data but not divide and conquer?
  10. 10. Pick Something Else! 10
  11. 11. And All Languages Got Everything • Actors, Akktors, Actorz, … • Threads, Locks • Fork/Join • Parallel Collections • Futures, Promises • Java’s util.concurrent • Channels • STM, Data Flow, … Ruby • Actors, Agents • Looks, Semaphores, Barriers • Atoms • Futures, Promises • Channels • Thread Pools • Thread-safe Array, Hash, … • STM, Data Flow, … 11
  12. 12. But, Not designed for Interaction! Clojure “designed to be a [.] language [.] with an efficient and robust infrastructure for multithreaded programming.” (dosync (future fun-with-sideeffect) "...") Haskell “an advanced [.] language [.] of cutting-edge research [.] with [.] built-in concurrency and parallelism” Control.Concurrent – MVar – Chan Control.Concurrent.STM – TMVar – TChan 12
  13. 13. Is it Just an Academic Issue? • Uses Locks and Atomic* • Multiple async. future/task abstractions • Multiple ‘transaction’ systems > 4500 “deadlock” bugs > 530 “race condition” bugs 13
  14. 14. Is it Just an Academic Issue? 14 Jaroslav Tulach 2007-03-21 08:41:46 UTC issue 75858 - e.g. calling 3rd party code from inside of runAtomicAction method issue 85858 when the 3rd party code called other code while holding internal locks. issue 95675 that broke web team & co. and five people were hunting for it for a week From: https://netbeans.org/bugzilla/show_bug.cgi?id=97278
  15. 15. WHAT CAN WE DO ABOUT IT? Concurrency without accidental complexity
  16. 16. Harmonize Concurrency Abstractions Desirable Properties – Free of low-level data races – Deadlock free – … Design Dimensions – Activity granularity • Lightweight vs. heavyweight – Blocking vs. non-blocking – Isolation • Granularity • Permanent vs. temporary • Optimistic vs. pessimistic – Deterministic vs. non-deterministic – … Actors STM many degrees of design freedom 16
  17. 17. Fundamental Elements as Building Blocks • Identify and formalize • Building blocks for languages and frameworks • Compose harmonious elements to guarantee – Deadlock freedom – Race freedom – … blocking non-blocking lightweight heavyweight 17
  18. 18. Actor Domains: Controlling Mutable State Actors STM Locks // new shared domain objCls = actor.newShared(Obj); obj = objCls<-new; obj.whenExclusive(o => { o mutate}); // new observable domain cntCls = actor.newObs(Counter); cnt = cntCls<-new; // synchronous, async. mutation print(cnt.read()); cnt<-inc; Actor model with safe data parallelism Work by Joeri De Koster Domains: Language Abstractions for Controlling Shared Mutable State in Actor Systems Joeri De Koster, PhD Dissertation, 2015 Actors 18 Locks STM
  19. 19. Deterministic Fork/Join 19 STM Future Promise Work by Janwillem Swalens Transactional Promises and Futures, Work in Progress (Paper Draft available on request) vec = Vector.make(10); prom = Promise.make(); atomic { f1 = future { process(vec,0,4); prom.resolve(42); // is safe }; f2 = future { process(vec,4,9); prom.get(); // read dependency }; } // throws exception on conflict
  20. 20. Approach: Design Combinations … Actors STM Locks STM Actors Locks Actors • One dominating abstraction • subordinates are assimilated 20
  21. 21. Better Insight into Building Blocks 21 To assemble useful combinations
  22. 22. Truffle-based Newspeak • Class-based • No global/static state • Value objects • Actors 22 NS 1.0 1.5 2.0 2.5 Bounce BubbleSort DeltaBlue Fannkuch Json Mandelbrot NBody PageRank Permute Queens QuickSort Richards Sieve Storage Runtimenormalized toJava 1.65x slower than Java min. -3%, max. 2.6x Research Platform for Actor Domains and Other Models
  23. 23. Future Plans Explore Safe Combinations • Complex concurrent systems – Funding proposal submitted – Collaboration of SSW & SOFT • Lightweight instrumentation • Independent of Concurrency Models Investigate Debugging 23 • Increase Applicability • Demonstrate Performance

Editor's Notes

  • - Fun fact, parallel ISA, but not really generally practical because they didn’t have synchronizing instructions
  • People have clearly been busy.
  • Solutions are design/applicable/natural for small sets of problems.
  • Not, let’s look at Netbeans, Jaroslav, let me know whether anything is wrong with this


    Not an academic problem
    People mix and match
    People suffer from bugs


    Argued for building different parts of a mail client with different concurrency abstractions before
    Looking at NetBeans and other applications, we see exactly that

    More than 4000 bugs with the term deadlock
    More
  • One dominating abstraction
    n subordinate abstractions
    Direct result
    n+1 language designs with fully integrated concurrency abstractions
    Building blocks for language design
    Formalization based on usage scenarios
    Identify groups of composable blocks
    Some properties are inherently incompatible


  • One dominating abstraction
    n subordinate abstractions
    Direct result
    n+1 language designs with fully integrated concurrency abstractions
    Building blocks for language design
    Formalization based on usage scenarios
    Identify groups of composable blocks
    Some properties are inherently incompatible


×