Understanding and preventing race conditons in Ruby

Race conditions are a common issue in concurrent programming that can lead to unexpected behavior and bugs in applications. In this article, we will explore race conditions in Ruby, illustrate them with code samples, and discuss techniques to prevent them.

What is a race condition?

A race condition occurs when two or more threads access shared data simultaneously, and the outcome of the operation depends on the relative timing of these threads. This can lead to unpredictable results and make it difficult to identify and reproduce bugs.

Illustrating Race Conditions in Ruby

Let's consider a simple Ruby script that demonstrates a race condition. The script simulates a bank account with a balance, where two threads attempt to deposit money simultaneously.

# race_condition_example.rb
class BankAccount
  attr_accessor :balance

  def initialize(balance)
    @balance = balance
  end

  def deposit(amount)
    new_balance = @balance + amount
    sleep(0.1)
    @balance = new_balance
  end
end

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

In this example, you might expect the final balance to be 220 (100 + 50 + 70). However, due to the race condition, the output could be 150 or 170, depending on the relative timing of the two threads.

Techniques to prevent race conditions in ruby

1. Mutex

A Mutex (short for "mutual exclusion") is a synchronization primitive that ensures only one thread can execute a particular section of code at a time. In Ruby, you can use the Mutex class to protect the critical section of your code, as shown in the example below:

# race_condition_mutex_example.rb
require 'thread'

class BankAccount
  attr_accessor :balance

  def initialize(balance)
    @balance = balance
    @mutex = Mutex.new
  end

  def deposit(amount)
    @mutex.synchronize do
      new_balance = @balance + amount
      sleep(0.1)
      @balance = new_balance
    end
  end
end 

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

By using a Mutex, we ensure that only one thread can access the deposit method at a time, preventing the race condition and yielding the expected final balance of 220.

2. Monitor

The Monitor class in Ruby is an extension of the Mutex class that provides additional methods for managing synchronization, such as try_enter and wait. You can use the MonitorMixin module to include Monitor functionality in your class:

# race_condition_monitor_example.rb
require 'monitor'

class BankAccount
  include MonitorMixin

  attr_accessor :balance

  def initialize(balance)
    @balance = balance
    super()
  end

  def deposit(amount)
    synchronize do
      new_balance = @balance + amount
      sleep(0.1)
      @balance = new_balance
    end
  end
end

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

In this example, we have included the MonitorMixin module and used the synchronize method to protect the critical section of our code. This ensures that only one thread can access the deposit method at a time, preventing the race condition and producing the expected final balance of 220.

Ruby on Rails: Dealing with Race Conditions

In Rails applications, race conditions can occur when multiple threads or processes modify shared resources, such as database records. To prevent race conditions in Rails, you can use ActiveRecord's built-in methods, such as with_lock:

class Order < ApplicationRecord
  has_many :line_items
  belongs_to :user

  def update_inventory
    line_items.each do |line_item|
      line_item.book.with_lock do
        new_inventory = line_item.book.inventory - line_item.quantity
        line_item.book.update!(inventory: new_inventory)
      end
    end
  end
end

In this example, we use the with_lock method to lock the book record before updating its inventory. This ensures that no other thread or process can modify the book's inventory simultaneously, thus preventing race conditions.

Understanding and preventing race conditions is crucial for developing stable and reliable concurrent applications in Ruby. By using synchronization techniques such as Mutex, Monitor, and ActiveRecord's built-in methods, you can protect critical sections of your code and ensure that your application behaves predictably even when multiple threads or processes access shared resources. As you continue to develop your Ruby applications, keep these concepts and techniques in mind to prevent race conditions and maintain the integrity of your data.

You can read more posts on the Maki Sushi blog.