What All Rubyists Should Know About Threads
summary
Shows that Ruby programs with threads break predictably: simple account example loses hundreds of thousands due to a race condition; adding a mutex synchronize around credit/debit fixes single-account races but creates cascading problems when transferring between two accounts, requiring double-checked locking or ordering by priority to avoid deadlock by locking multiple resources. Demonstrates a 1‑in‑a‑million failure rate in homegrown lock hacks, cites a threaded bug in rake, and suggests using Erlang or Clojure’s transactional refs for safer concurrency.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 2:40Clock Speed
- 5:56HyperThreading
- 7:26Applications Need to be Concurrent
- 8:35Learn to Program Like Your Mom
- 11:11Concurrent Program
- 13:43Race Condition
- 16:15Critical Region
- 24:05Syncing Accounts
- 25:22Explicit Sync
- 29:39Multithreading
- 31:41RealTime Data
- 33:14One in a Million
- 34:58DoubleCheck Lock
- 38:58Tail Recursion
- 42:01Lisp
- 42:25Numbers
- 45:59Summary
related talks
42mLook out! Gotchas of Using Threads in Ruby
38mScaling Ruby with Actors, or How I Learned to Stop Worrying and Love Threads
12mDon’t Be ‘Thread’-ened: Testing Multithreaded Code with Confidence
39mConcurrent Systems in Ruby
33mConcurrency for !Dummies (Who Don't Get It (...Yet))
19mThread Safety First!
36mModern Concurrency Practices in Ruby
43mRuby: The Challenges Ahead