Learn Ruby - Concurrency & Parallelism (Thread, Fiber, Ractor)

#Introduction

Modern applications must serve many users at once, process many requests, and not waste time waiting on I/O. In Ruby, concurrency is handled by three different tools with different philosophies: Thread for concurrent execution with shared state, Fiber for lightweight cooperation that can be paused and resumed, and Ractor for true parallelism safe from race conditions.

This episode 11 dissects all three progressively. We start with Thread with Mutex and Queue, then Fiber with a scheduler for async I/O, and end with Ractor along with the new Ractor::Port API in Ruby 4.0. Recall the GVL explanation from episode 2: Ruby threads are concurrent for I/O, but only Ractor is truly parallel for CPU.

#Threads and Race Conditions

#Basic Threading

Thread.new creates a new thread that runs concurrently. The join method waits for a thread to finish — without it, the main program can end before the thread does its work:

Basic threading

threads = 3.times.map do |i|
  Thread.new do
    sleep(0.1)
    puts "Thread #{i} selesai"
  end
end
threads.each(&:join)
puts "Semua selesai"

Thread.new do ... end creates a thread that executes the block. threads.each(&:join) calls join on every thread, ensuring the main program waits for all of them. Without join, the output Semua selesai could appear first. Threads suit workloads dominated by waiting on I/O like HTTP or databases.

#Race Conditions and Mutex

Because threads share state, two threads modifying the same variable at the same time can produce wrong values — this is a race condition. The solution is Mutex (mutual exclusion), which ensures only one thread at a time:

Race condition with Mutex

counter = 0
mutex = Mutex.new
threads = 10.times.map do
  Thread.new do
    10_000.times do
      mutex.synchronize { counter += 1 }
    end
  end
end
threads.each(&:join)
puts counter

Without mutex.synchronize, the counter result is almost certainly less than 100,000 because the += operation isn't atomic. With Mutex, the result is exactly 100,000. Monitor is a reentrant variant; Queue from the thread-safe family provides a safe queue for communication between threads.

#Queue and Return Values

Queue lets threads share data safely: one thread writes, another reads with pop, which blocks until data is available:

Queue between threads

queue = Queue.new
Thread.new { 5.times { |i| queue << i } }
puts queue.pop
puts queue.pop

queue << i inserts data, and queue.pop takes it out. The second pop call waits for the next piece of data to become available — no busy loop wasting CPU. A thread's return value can be retrieved with thread.value, which also waits for the thread to finish.

#Fiber and Scheduler

#Cooperative Concurrency

Fiber is a lightweight execution unit that stops and resumes explicitly — called cooperative because the switch of control is managed by the programmer, not the operating system. Fiber.yield suspends a fiber, resume continues it:

Basic Fiber

fiber = Fiber.new do
  puts "mulai"
  Fiber.yield "di tengah"
  puts "lanjut"
  "selesai"
end
 
puts fiber.resume
puts fiber.resume
puts fiber.resume

The first fiber.resume runs until Fiber.yield and returns "di tengah". The second resume continues from the last point and returns "selesai". Fibers are far lighter than threads — thousands of fibers can live in a single thread.

#Fiber.scheduler and Async I/O

Fiber.scheduler is an interface that allows blocking I/O (like reading from a socket) to be suspended and handled asynchronously within a single thread. A scheduler is injected with Fiber.set_scheduler, and libraries like async use it to handle thousands of concurrent connections with low overhead. This is the secret of high-performance Ruby servers handling many network connections.

#Ractor: True Parallelism

#Ractor.new and the Isolation Model

Ractor (Ruby Actor) executes code in true parallelism outside the GVL constraint. Its safety is guaranteed by isolation: objects aren't shared between ractors unless declared shareable. Creating a ractor is just like creating a thread, but with strict data isolation:

Basic Ractor

rakt = Ractor.new { 21 * 2 }
rakt.join
puts rakt.value

rakt.join waits for the ractor to finish, and rakt.value takes the result of the computation. Because no state is shared, the race conditions we saw with Thread are impossible here. Ractor is Ruby's answer for utilizing multiple CPU cores.

#Ractor::Port in Ruby 4.0

Ruby 4.0 introduces Ractor::Port — a new ractor communication API that replaces Ractor.yield and Ractor.take. Communication is now viewed as ports: ractors communicate through explicit message channels. Ractor.select allows one ractor to wait for messages from many ports at once. Ractor.shareable_proc ensures that procs sent between ractors are immutable and safe to share.

For a parallel map workload, a ractor-per-item combination works like this:

Parallel map with Ractor

data = (1..4).to_a
hasil = data.map do |nilai|
  Ractor.new(nilai) { |n| n * n }
end.map(&:value)
puts hasil.inspect

Ractor.new(nilai) { |n| n * n } wraps each computation in a ractor that runs in parallel, then map(&:value) retrieves each result. On a multi-core CPU, the four squares are computed concurrently, not sequentially. Note: creating too many ractors has overhead, so measure with profiling — the subject of episode 17.

#Conclusion

Episode 11 opens up the world of Ruby concurrency: Thread with Mutex, Queue, and join, Fiber with Fiber.yield and Fiber.scheduler for async I/O, and Ractor for true parallelism with the new Ractor::Port API in Ruby 4.0.

Key takeaways:

• Threads are concurrent for I/O; race conditions are prevented with Mutex and Queue.
• thread.join and thread.value wait for and retrieve thread results.
• Fibers run cooperatively with resume and Fiber.yield.
• Fiber.scheduler enables asynchronous I/O within a single thread.
• Ractors run in parallel outside the GVL with strict object isolation.
• Ruby 4.0 introduces Ractor::Port, replacing Ractor.yield and Ractor.take.
• Ractor.select and Ractor.shareable_proc round out the inter-ractor communication API.

In the next episode, episode 12, we will discuss RubyGems, Bundler, and dependency management — gem install and gem search, gemspec structure, creating gems with bundle gem, Gemfile and bundle install, Gemfile.lock with checksums, multi-gem sources, and dependency groups. This is where you learn to manage libraries like a professional developer.