Download as KEY, PPTX
Uploaded byMike Subelsky
Ruby Concurrency Realities
This document discusses different approaches to concurrency in Ruby including processes, threads, actors, fibers, and events. Processes provide simple concurrency but require starting each process and can't share resources. Threads provide concurrency within a process but require careful use to avoid bugs. Actors and fibers provide lightweight concurrency models based on message passing. Events provide high-performance concurrency using an event loop but code can become complex. The best approach depends on specific needs and runtime.
More Related Content
![[131] packetbeat과 elasticsearch](https://cdn.slidesharecdn.com/ss_thumbnails/113packetbeatelasticsearch-150914020054-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
Ruby Concurrency Realities
- 1. Ruby Concurrency Slides &links posted to
- 2.
- 3.
- 4. What Is Inefficient? CPU Idling While You
- 5. What Is Inefficient? Not Using All of Your
- 6.
- 7. Completely Hadoop
- 8. Completely Hadoop
- 9. Forked Processes http://tomayko.com/writings/unicorn-is-unix Ruby subprocess
- 10. Forked Processes http://tomayko.com/writings/unicorn-is-unix Ruby subprocess
- 11.
- 12. Many Ways toStart system, exec, IO.popen,
- 13. Complex Fork Spork, Unicorn,
- 14. Copy-on-Write Rubinius, Enterprise
- 15. Copy-on-Write Rubinius, Enterprise
- 16.
- 17. Process Concurrency •Requires youto start/monitor each process •Requires some type of RPC (dRb, Resque, etc) •Can’t share resources (like connection pools) •Memory inefficient w/o copy-on-write •One process per core
- 18. Thread Concurrency http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/ Concurrency within a
- 19. Thread Concurrency http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/ Concurrency within a
- 20.
- 21.
- 22.
- 23. Complex Thread Mongrel
- 24. Green Threads •VM-managed •Lightweight •1 percore •Blocking I/O blocks all threads
- 25. Native Threads •Scheduled byOS •Do not block other threads during I/O •Can run on multiple cores*
- 26. *Global Interpreter Lock •Onlyallows one thread to run at a time •Ruby C code not threadsafe •Released during I/O
- 27. Released During I/O http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/
- 28. Rubies without GIL http://www.engineyard.com/blog/2011/ruby-concurrency-and-you/
- 29. Thread Safety http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/
- 30. Thread Safety http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/
- 31. Thread Safety ruby thread.rb = 200000 jruby thread.rb = 1067198 http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/
- 32.
- 33. Thread Safety Queue, SizedQueue,
- 34. Thread Pros •More intuitivethan fibers/events •Sans GIL: most efficient/performant* technique •Single process to monitor •Shared resources, no RPC •Fine-grained control of thread lifecycle *http://teddziuba.com/2011/10/straight-talk-on-event-loops.html
- 35. Thread Cons •Increased complexity(vs processes) •Notoriously hard to debug •Potential for deadlocks and race conditions Text
- 36. Actor Concurrency Message passing vs.
- 37. Actor Concurrency Message passing vs.
- 38. Actor Concurrency “Threads that don’t
- 39. Actor Concurrency http://mperham.github.com/girl_friday/ girl_friday
- 40. Where You CanGet •JRuby and Rubinius Actor API •celluloid gem Text
- 41. Fiber Concurrency Manually scheduled
- 42. Fiber Concurrency •Code blocksthat can be paused/resumed •Lighter than threads, cannot be preempted •Scheduled by programmer •Can share data without mutexes Manually scheduled
- 43. Simple Fiber Example http://paulbarry.com/articles/2010/04/01/fibers-in-ruby-1-9
- 44. Complex Fiber Example Goliath,em-synchrony,
- 45. Complex Fiber Example Goliath,em-synchrony,
- 46. Fiber Pros •Much lightermemory use than threads •Faster to start vs threads •Can share data without mutex •Can simplify asynchronous APIs (em-synchrony) Text
- 47. Fiber Cons •Limited toone CPU core •Nonintuitive •Syntax can get confusing •Need to use fiber-aware libraries for I/O Text
- 48. Event Concurrency Single-thread w/
- 49. Event Concurrency Single-thread w/
- 50.
- 51. EventMachine Pros •Performs wellunder heavy network I/O •Zero overhead •Can still use threads via EM.defer
- 52. EventMachine Cons •Inversion ofcontrol can be confusing •Hard to test •Nested callbacks can lead to spaghetti code •Threads can still beat events (all apps will eventually become CPU bound)
- 53. General Advice: MRI Threads/Actors Threads/Actors Events Threads/Actors Forks/Processes Fibers (synchrony)
- 54. General Advice: JRuby/ Threads/Actors Threads/Actors Threads/Actors Events
- 55. Links on subelsky.com Questions? @subelsky