DEV Community

Anand Soni
Anand Soni

Posted on

How to Use Mutex in Ruby: A Comprehensive Guide

Image description

Introduction

Concurrency is a powerful tool in programming, enabling multiple threads to execute code simultaneously. However, with this power comes the responsibility to manage shared resources safely. In Ruby, Mutex (short for mutual exclusion) is a key component in ensuring that only one thread can access a resource at a time, preventing potential data corruption or unpredictable behaviour.
In this blog, we'll explore how to use Mutex in Ruby, supported by sample code and a real-life scenario to illustrate its practical application.

What is a Mutex?

A Mutex is an object used to manage the synchronization of threads. When one thread locks a Mutex, any other thread that attempts to lock the same Mutex will be put on hold until the first thread releases it. This mechanism ensures that critical sections of code, where shared resources are accessed, are executed by only one thread at a time.

Why Use a Mutex?

Imagine a scenario where multiple threads are modifying the same variable or writing to the same file. Without proper synchronization, the result could be unpredictable or incorrect. A Mutex helps to avoid such issues by ensuring that only one thread can access the shared resource at any given time.

How to Use Mutex in Ruby

require 'thread'

# Initialize a Mutex
mutex = Mutex.new

# Shared resource
counter = 0

# Create threads
threads = 10.times.map do
  Thread.new do
    1000.times do
      # Lock the mutex before modifying the shared resource
      mutex.synchronize do
        counter += 1
      end
    end
  end
end

# Wait for all threads to finish
threads.each(&:join)

puts "Final counter value: #{counter}"
Enter fullscreen mode Exit fullscreen mode

In this example:

  • We initialize a Mutex object.
  • We create a shared resource (counter) that will be accessed by multiple threads.
  • We create 10 threads, each incrementing the counter 1000 times.
  • Inside the mutex.synchronize block, we ensure that only one thread can modify the counter at a time.
  • Finally, we print the final value of counter, which should be 10000 if the Mutex has properly synchronized the access.

Real-Life Scenario: Managing Bank Account Transactions

To understand the real-life application of Mutex, let's consider a scenario where multiple threads represent transactions on a bank account. Each transaction may involve depositing or withdrawing money, and we must ensure that the account balance remains accurate.

require 'thread'

# Initialize a Mutex
account_mutex = Mutex.new

# Bank account class
class BankAccount
  attr_reader :balance

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

  def deposit(amount)
    @balance += amount
  end

  def withdraw(amount)
    @balance -= amount
  end
end

# Shared bank account
account = BankAccount.new(1000)

# Transactions
threads = []

# Deposit thread
threads << Thread.new do
  100.times do
    account_mutex.synchronize do
      account.deposit(50)
    end
  end
end

# Withdraw thread
threads << Thread.new do
  100.times do
    account_mutex.synchronize do
      account.withdraw(30)
    end
  end
end

# Wait for all threads to finish
threads.each(&:join)

puts "Final account balance: #{account.balance}"
Enter fullscreen mode Exit fullscreen mode

In this scenario:

  • We define a BankAccount class with deposit and withdraw methods.
  • We create a shared BankAccount instance with an initial balance of 1000.
  • We create two threads: one for depositing money and one for withdrawing money.
  • We use a Mutex to synchronize access to the deposit and withdraw methods, ensuring that only one transaction can modify the account balance at a time.
  • Finally, we print the final account balance, which should accurately reflect all transactions.

Conclusion

Using Mutex in Ruby is essential when dealing with concurrency and shared resources. It provides a simple yet effective way to ensure that only one thread can access a critical section of code at a time, preventing potential issues like data corruption or race conditions.

Top comments (0)