When I first started building Ruby applications, I noticed that some tasks took forever to complete. My programs would wait for one operation to finish before starting the next, even when they didn’t depend on each other. This felt inefficient, like having a single cashier in a busy store while other registers stayed empty. That’s when I discovered concurrency, which allows multiple tasks to happen at the same time. In Ruby, this can significantly speed up applications, but it requires careful handling to avoid common pitfalls.

Ruby has something called the Global Interpreter Lock, or GIL. This means that only one thread can execute Ruby code at a time in a single process. It might sound limiting, but with the right patterns, we can still achieve impressive performance gains. Over time, I’ve learned to use various concurrency techniques depending on the situation. Let me share some of the most effective ones I’ve applied in real projects.

Threads are a common starting point for concurrency. They let you run multiple parts of your code simultaneously within the same process. Since threads share memory, you need to be cautious about how they access data to prevent conflicts. I remember working on a file processing script that was painfully slow. By using threads, I cut the processing time dramatically.

Here’s a basic example of how I use threads to handle multiple files at once. Each file is read and processed in its own thread, which allows the program to work on several files concurrently. After starting all threads, the join method ensures the main program waits for everything to finish.

class ParallelProcessor
  def process_files(files)
    threads = files.map do |file|
      Thread.new do
        content = File.read(file)
        process_content(content)
      end
    end
    threads.each(&:join)
  end

  private

  def process_content(content)
    # Simulate a task that takes time, like calculating a hash
    digest = Digest::SHA256.hexdigest(content)
    Rails.logger.info "Processed: #{digest}"
  end
end

processor = ParallelProcessor.new
processor.process_files(Dir.glob('data/*.txt'))

In this code, Thread.new creates a new thread for each file. The process_content method does the actual work, such as computing a SHA256 hash. Using threads here makes sense because reading files involves waiting for I/O, and other threads can run during that wait. However, if multiple threads try to modify the same data at once, you might get unexpected results. I always use mutexes or other synchronization tools when threads need to share mutable state.

Fibers offer a lighter alternative to threads. They are like threads but with less overhead because you control when they run. I find fibers useful for tasks that involve a lot of waiting, such as handling network requests. In one project, I used fibers to manage multiple chat connections without bogging down the system.

Here’s a simple scheduler I built to manage fibers. It allows tasks to yield control back to the scheduler, enabling cooperative multitasking. This means fibers work together by taking turns, which can be more efficient than preemptive threading.

class FiberScheduler
  def initialize
    @fibers = []
  end

  def add_task(&block)
    @fibers << Fiber.new(&block)
  end

  def run
    until @fibers.empty?
      fiber = @fibers.shift
      fiber.resume
      @fibers << fiber if fiber.alive?
    end
  end
end

scheduler = FiberScheduler.new
scheduler.add_task { 3.times { |i| puts "Task A: #{i}"; Fiber.yield } }
scheduler.add_task { 3.times { |i| puts "Task B: #{i}"; Fiber.yield } }
scheduler.run

In this example, Fiber.yield pauses the fiber and returns control to the scheduler. The alive? method checks if the fiber has more work to do. Fibers consume less memory than threads, making them ideal for applications with many concurrent I/O operations. I’ve used this in web servers to handle multiple requests efficiently without the complexity of full threading.

The actor model is another pattern I rely on for building robust concurrent systems. Actors are independent entities that communicate by sending messages to each other. This avoids shared state, which reduces the risk of data corruption. I used the concurrent-ruby gem to implement actors in a payment processing system, where each transaction was handled by a separate actor.

Here’s how you can set up a pool of worker actors. Each actor processes messages in isolation, and the supervisor manages the pool. This approach makes it easy to scale and handle failures gracefully.

class Worker < Concurrent::Actor::RestartingContext
  def on_message(message)
    case message
    when :process
      perform_work
      :done
    when :status
      :ready
    end
  end

  private

  def perform_work
    # Simulate a task, like processing a payment
    sleep(0.1)
  end
end

supervisor = Concurrent::Actor::Utils::Pool.spawn!('workers', 3) do |index|
  Worker.spawn(name: "worker-#{index}")
end

futures = 5.times.map { supervisor.ask(:process) }
results = futures.map(&:value)

In this code, actors handle messages like :process and :status. The ask method sends a message and returns a future, which you can use to get the result later. I like this pattern because it keeps code modular and safe. If one actor crashes, it doesn’t affect others, and the restarting context can bring it back online.

Event-driven programming is perfect for I/O-heavy applications. Instead of blocking threads, you use events to handle operations as they complete. I built a real-time notification service using EventMachine, which allowed the server to handle thousands of connections without multiple threads.

Here’s a basic echo server using EventMachine. It listens for incoming data and responds immediately, all within a single thread. This avoids the overhead of context switching between threads.

require 'eventmachine'

class EchoServer < EM::Connection
  def receive_data(data)
    send_data "Echo: #{data}"
    close_connection if data.strip == 'quit'
  end
end

EM.run do
  EM.start_server('0.0.0.0', 8080, EchoServer)
  EM.add_timer(1) { puts "Server running on port 8080" }
end

The receive_data method is called whenever data arrives. send_data sends a response, and close_connection ends the session. EventMachine manages all I/O events in the background, making it efficient for network applications. I’ve found this pattern especially useful for chat apps or APIs that need low latency.

Process-based parallelism is a powerful way to bypass Ruby’s GIL. By using multiple processes, each with its own Ruby interpreter, you can achieve true parallelism. I used this for data analysis tasks where CPU-intensive calculations were the bottleneck. The parallel gem makes it straightforward to distribute work across processes.

Here’s an example of processing a large dataset in parallel. The map function splits the work among several processes, each handling a chunk of data.

require 'parallel'

class DataProcessor
  def process_large_dataset(data)
    Parallel.map(data, in_processes: 4) do |chunk|
      heavy_computation(chunk)
    end
  end

  private

  def heavy_computation(data)
    # A simple example of CPU-heavy work
    data * data
  end
end

processor = DataProcessor.new
result = processor.process_large_dataset(1..1000)

Parallel.map takes care of dividing the data and collecting results. Since each process has its own memory, there’s no risk of thread safety issues. However, inter-process communication can add overhead, so I use this for tasks where the computation time outweighs the cost of data transfer.

Async/await patterns bring modern concurrency features to Ruby. They make it easy to write asynchronous code that looks synchronous, which improves readability. I’ve used the async gem in web scrapers to fetch multiple URLs simultaneously without blocking.

Here’s how you can fetch several API endpoints at the same time. The async block creates a context for concurrent tasks, and task.async starts each fetch operation.

require 'async'

class ApiClient
  def fetch_multiple_endpoints(urls)
    Async do |task|
      urls.map { |url| task.async { fetch_url(url) } }.map(&:wait)
    end
  end

  private

  def fetch_url(url)
    # Simulate an HTTP request
    sleep(0.5)
    { url: url, data: "response from #{url}" }
  end
end

client = ApiClient.new
responses = client.fetch_multiple_endpoints(['/api/users', '/api/posts'])

The wait method collects all results once the tasks are done. This pattern is great for I/O-bound operations because it keeps the code clean and easy to follow. I prefer it over raw threads for simple asynchronous tasks.

Thread pools help manage resources efficiently by reusing a fixed number of threads. Creating and destroying threads repeatedly can be costly, so pools keep a set of threads ready for work. I implemented a thread pool in a background job processor to handle many small tasks without overhead.

Here’s an example using Concurrent::FixedThreadPool. It submits tasks to a pool of threads and uses futures to track their progress.

class ThreadPoolExecutor
  def initialize(pool_size: 5)
    @pool = Concurrent::FixedThreadPool.new(pool_size)
    @futures = []
  end

  def submit_task(&block)
    future = Concurrent::Future.execute(executor: @pool, &block)
    @futures << future
    future
  end

  def wait_for_completion
    @futures.each(&:value)
  end
end

executor = ThreadPoolExecutor.new
10.times do |i|
  executor.submit_task do
    puts "Processing task #{i} in thread #{Thread.current.object_id}"
    i * i
  end
end
executor.wait_for_completion

The FixedThreadPool ensures that no more than the specified number of threads run at once. Futures allow you to check results later. This pattern is ideal for applications with frequent, short-lived tasks, as it avoids the cost of creating new threads each time.

Choosing the right concurrency pattern depends on your specific needs. For I/O-bound tasks, fibers or event-driven approaches work well. CPU-intensive jobs benefit from process-based parallelism. When you need isolation and fault tolerance, the actor model is a good fit. Thread pools are excellent for managing resources in high-throughput systems.

I always start by profiling my application to identify bottlenecks. Then, I select the pattern that addresses those issues without adding unnecessary complexity. Testing is crucial because concurrency can introduce subtle bugs that are hard to reproduce.

In my experience, combining these patterns can yield the best results. For instance, using actors within a thread pool or mixing async/await with fibers. The key is to understand the trade-offs and apply them judiciously.

Concurrency in Ruby has come a long way, and with these patterns, you can build applications that are both fast and reliable. I encourage you to experiment with them in your projects. Start with simple cases and gradually incorporate more advanced techniques as you grow comfortable. Remember, the goal is to make your code efficient without sacrificing clarity or stability.