Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Brief Introduction to Concurrent Programming


Published on

This presentation reviews a few of the basic issues with concurrency, and compares object oriented approaches to solving these problems with functional approaches.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Brief Introduction to Concurrent Programming

  1. 1. Rob Keefer, PhD
 @rbkeefer A Brief Introduction to Concurrent Programming
  2. 2. @rbkeefer Goal Goal of Concurrency is to get more done in less time. Multiple independent tasks Repeat same task Solution: Parallelism
  3. 3. @rbkeefer Parallelism
  4. 4. @rbkeefer Direction Processes Problems with Concurrency Traditional Solutions New Approaches
  5. 5. @rbkeefer Turn the Crank
  6. 6. @rbkeefer Processor
  7. 7. @rbkeefer Processor
  8. 8. @rbkeefer Processor
  9. 9. @rbkeefer Processor
  10. 10. @rbkeefer Take Advantage of the Tech
  11. 11. @rbkeefer Problems 1. Starting / maintaining processes 2. Communication between processes • Remote procedure call (RPC) • Message passing 3. Shared Resources • Deadlock • Livelock • Race conditions • Starvation
  12. 12. @rbkeefer Five Volunteers
  13. 13. @rbkeefer Problems: Deadlock
  14. 14. @rbkeefer Problems: Livelock
  15. 15. @rbkeefer Problems: Race Condition
  16. 16. @rbkeefer Problems: Starvation
  17. 17. @rbkeefer Approaches Traditional Object Oriented Modern Functional General Philosophy: Failure Prevention General Philosophy: Embrace Failure Monitor Mutual Exclusion (Mutex) Prioritization Algorithms Support process death and resurrection Support atomic functions Fairness algorithms embedded in VM
  18. 18. @rbkeefer Monitor
  19. 19. @rbkeefer Mutex
  20. 20. @rbkeefer def call(process_name, message, timeout 5000) ref = Process.monitor(process_name) try do send(process_name, {:message, {ref, self()}, message}) rescue _ -> :error end receive do {:reply, ref, reply} -> Process.demonitor(ref, [:flush]) reply {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) after timeout -> exit(:timeout) end end Elixir - Lock Prevention <- exit on timeout
  21. 21. @rbkeefer def answer(process_name, message, timeout 5000) receive do {:knock, ref, reply} -> reply # "Who's there?" {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) # No one knocking after timeout -> exit(:timeout) end . . . def knock(process_name, message, timeout 5000) receive do {:reply, ref, reply} -> reply # Tell who you are {:DOWN, ref, :process, _, reason} -> {:error, reason} exit(reason) # No one home after timeout -> exit(:timeout) end . . . Elixir - Race Condition <- exit on timeout <- exit on timeout
  22. 22. @rbkeefer Note on Garbage Collection Credit: Greg Mefford
  23. 23. @rbkeefer A Few Facts Traditional Object Oriented Modern Functional Bring data and behaviors together Simulation of behavior (heuristics) Overhead: Java threads 512 Kb / thread Require thread pools / execution management Shared heap Hard limits on memory use Separate data from behaviors Data manipulation (algorithms) Overhead: Elixir 512 b / process Processes easily accessible Individual private heap Unbounded memory
  24. 24. @rbkeefer Scale with Resilience Resilience: ability of a system to adapt or keep working when challenges occur
  25. 25. @rbkeefer Questions to Consider Think Different: Fault Tolerance: What happens if a dependency starts failing slowly? What’s the worse-scenario for total failure? Efficiency: Is it possible to precompute data? Are you doing as little work as possible? Is load testing part of the regression test suite? Operability: Where are the nonlinearities in load or failure responses? What are the capacity needs? How does the system scale?
  26. 26. @rbkeefer Continue the Conversation Rob Keefer, PhD @rbkeefer