Ruby Concurrency
Download as PPTX, PDF2 likes566 views
This document discusses various models for handling concurrency including actors, mutexes/locks, software transactional memory (STM), communicating sequential processes (CSP), futures/promises, coroutines, and evented I/O. It describes the execution, scheduling, and communication mechanisms of each model and compares their pros and cons. Key points covered include the differences between concurrency and parallelism, atomicity problems with shared memory, advantages of message passing over shared memory, and event-driven non-blocking I/O can scale well compared to spawning many threads.
Ruby Concurrency
- 1. or Concurrency Hell How I stopped worrying about it Egor Hamaliy
- 2. Agenda 1. Concurrency and Parallelism 2. General Concepts 3. Models
- 4. • Actors • Mutexes/Locks • STM • CSP • Futures/Promises • … Models
- 5. Models • Coroutines • Evented IO • Process calculi • Petri nets • ...
- 8. Concurrency vs Parallelism What’s the difference ?
- 9. Not all programmers agree on the meaning of the terms 'parallelism' and 'concurrency'. They may define them in different ways or do not distinguish them at all.
- 10. Rob Pike
- 11. Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once. http://blog.golang.org/concurrency-is-not-parallelism Rob Pike
- 14. Execution How things are executed?
- 15. • Process • Thread • Green Thread OS Primitives
- 16. Scheduling How things are scheduled?
- 17. Preemptive
- 18. Cooperative
- 19. Communication How do the executing things not trip over each other?
- 20. Communication is always HARD
- 21. Models Threads/Mutexes Transactional Memory Processes & IPC CSP Evented/Coroutines Actors Part #2
- 22. Model Execution Scheduling Communication Concurrent/P arallel Implementation Mutexes Threads Preemptive Shared Memory(locks) C/P Mutex Transactional Memory Threads Preemptive Shared memory(commit/abort) C/P Clojure STM Processes & IPC Processes Preemptive Shared memory/Message passing C/P Resque/Forking CSP Threads/Proc esses Preemptive Message passing(channels) C/P Golang Actors Threads Preemptive Message passing(mailboxes) C/P Erlang/Celluloid Futures & Promises Threads Cooperative Message passing(itself) C/P Oz/Celluloid Coroutines 1 process/threa d Cooperative Message passing C Fibers Evented 1 process/threa d Cooperative Shared memory C Eventmachine
- 24. Mutex
- 25. Pros • No need to worry about scheduling (preemptive) • Commonly used • Wide language support Cons • Scheduling overhead (context switching) • Synchronization/locking issues Mutex
- 26. http://en.wikipedia.org/wiki/Software_transactional_memory "After completing an entire transaction verifies that other threads have not made changes to memory that it accessed in the past...If validation is successful, made permanent, is called a commit." "May also abort at any time." Transactional Memory
- 27. Thread1: atomic { - read variable - increment variable - write variable } Thread2: atomic { - read variable - increment variable # going to write, but Thread1 has written variable... # notices Thread1 changed data, so ROLLS BACK - write variable } “Don't wait on a lock, just check when we're ready to commit” Transactional Memory
- 29. Pros • Increased concurrency • No thread needs to wait for access to a resource • Smaller scope that needs synchronizing - modifying disjoint parts of a data structure STM's benefits http://www.haskell.org/haskellwiki/Software_transactional_memory Cons • Aborting transactions • Places limitations on the behavior of transactions - they cannot perform any operation that cannot be undone, including most I/O. Transactional Memory
- 30. Methods of IPC • Pipes • Shared memory • Message queues IPC
- 31. How do we handle atomicity? Don't share memory. How to communicate? IPC
- 32. Pros • Can't corrupt data when data is not shared. • No locking. • Easier to scale horizontally (adding nodes). Cons • Can't communicate over shared memory • Slower to spawn a new process • More memory overhead. • Scaling horizontally is expensive. IPC
- 34. Pros • Uses message passing and channels heavily, alternative to locks Cons • Handling very big messages, or a lot of messages, unbounded buffers • Messaging is essentially a copy of shared CSP
- 35. Actors
- 36. Atomicity? Conflict? Every actor has it's own address space. Don't share memory. Communicate via mailboxes. Actors
- 37. Comparison with CSP • CSP processes are anonymous, while actors have identities. • Message-passing in actor systems is fundamentally asynchronous (CSP traditionally uses synchronous messaging: "rendezvous") • CSP uses explicit channels for message passing, whereas actor systems transmit messages to named destination actors. Actors
- 38. Pros • Uses message passing and channels heavily • No shared state (avoid locks, easier to scale) • Easier to maintain the code Cons • When shared state is required doesn't fit as well • Handling very big messages, or a lot of messages • Messaging is essentially a copy of shared data Actors
- 39. Fibers
- 40. Fibers are coroutines: Cooperative! Handing execution rights between one another, saving local state. Fibers
- 41. A Curious Course on Coroutines and Concurrency: David Beazley (https://twitter.com/dabeaz) writing an operating system with only coroutines. http://dabeaz.com/coroutines/ No Threads, Evented style, just cooperative scheduling of coroutines... Possible use cases: http://stackoverflow.com/questions/303760/what-are-use-cases-for-a- coroutine Fibers
- 42. Pros • Expressive state: state based computations much easier to understand and implement • No need for locks (cooperative scheduling) • Scales vertically (add more cpu) Cons • Single thread: Harder to parallelize/scale horizontally (use more cores, add more nodes) • Constrained to have all the components work together symbiotically Fibers
- 43. Eventmachine
- 44. Examples • C10k problem • Eventmachine in ruby • Twisted in python • Redis's event loop • Apache vs Nginx • Node.js vs the world Eventmachine
- 45. Eventmachine “Evented servers are really good for very light requests, but if you have a long-running request, it falls down on its face” Technically, valid, but in practice, not necessarily true.
- 46. Eventmachine Reactor: • wait for event (Reactor job) • dispatch "Ready-to-Read" event to user handler (Reactor job) • read data (user handler job) • process data ( user handler job) Proactor: • wait for event (Proactor job) • read data (now Proactor job) • dispatch "Read-Completed" event to user handler (Proactor job) • process data (user handler job)
- 47. Pros • Avoid polling. CPU bound vs IO bound • Expanding your horizons (very different paradigms) • Scales well vs spawning many threads Cons • You block the event loop, all goes bad • Program flow is "spaghetti"-ish • Callback Hell • Hard to debug, you loose "the stack” Eventmachine
- 49. Conclusion
- 50. USE THE BEST TOOL FOR THE JOB
- 51. Questions?