What is the Global VM Lock and how does it affect concurrency?
Assesses fundamental understanding of Ruby conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
MRI, the standard Ruby implementation, has a Global VM Lock: only one thread executes Ruby bytecode at a time, so threads do not provide CPU parallelism for pure Ruby code. They do improve concurrency for I/O because the lock is released around blocking operations such as file, socket and database calls.
threads = urls.map do |url|
Thread.new { fetch(url) } # overlaps I/O, not CPU
end
results = threads.map(&:value)
For CPU-bound work you need process-level parallelism: fork, the Process API, multiple server workers under Puma or Unicorn, or a different implementation such as JRuby or TruffleRuby, which have no GVL.
Since Ruby 3.0 the lock is more granular, and Ractors offer actor-style parallelism in limited cases. Concurrency primitives include Mutex, ConditionVariable and Queue. Choose processes for parallelism and threads for overlapping I/O.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.