---

Threads:

We all know what a process is it is a unit of work with a single thread of control.Thread is also a lightweight process. The main difference between process and threads is that threads within the same process run in shared memory space, while processes run in separate memory spaces.

Using threads helps to achieve concurrency. A process can have multiple threads. Each thread will act as a separate process

Today we will learn about how to use threads in ruby to achieve better performance.Before diving into code, let's get familiar with some necessary concepts.

Scheduler:

The main job of the scheduler is to move the process from queues to CPU or from one queue to a different queue

In actual OS, there will be more schedulers. For simplicity's sake, we define two schedulers: job scheduler and CPU scheduler and ready-queue to store the process metadata

When a process is generated we store the process in the process pool. The job scheduler will take the process from the pool and add it to the ready queue, Cpu Scheduler will take the process which is ready to execute from the Queue and allocates CPU resources to it.

CPU Scheduler works based on round robin algorithm and it will allocate constant to each process from the queue, once allocated time is done, It will need to save the context of the current running process and restore the context of the next available process from the queue, this is called context switching. context switch time is purely overhead

Context switch time for threads is less compared to single thread process because threads within the same process run in a shared memory space

Let's create a simple method in ruby and execute it in IRB or console

        
    def step(v) 
        sleep(v/10.0) # suspends the execution 
        puts "step#{v}" 
    end
        
      

step method accepts integer/float as input sleep for (input/10.0) seconds then prints a statement in the console

Lets do some benchmark analysis w/o threads on this method

        
    Benchmark.realtime do 
        10.times do 
            step(1) 
            step(2) 
            step(3) 
        end 
    end 
    #took 6.010479167001904 seconds 
        
      

        
    Benchmark.realtime do 
        threads = [] 
            100.times do 
                threads << Thread.new { step(1) } 
                threads << Thread.new { step(2) } 
                threads << Thread.new { step(3) } 
            end 
        threads.each(&:join) 
    end # 0.4057327560003614 seconds
        
      

In the first scenario, we called the method 30 times, total execution time is 6.01 seconds.

In the second scenario, we called the method 300 times total execution time is 0.4 seconds

We spawned a new thread every time when we call the step, all threads are executed concurrently with minimum context switch time

DataRace:

DataRace occurs when one thread access a mutable object while another thread writing to it. lets consider below example

        
    val = [0, 0] 
    threads = (0...5).map do 
        Thread.new do 
            1000000.times do 
                val.map! { |c| c + 1 }
            end 
        end 
    end 
    threads.each(&:join) 
    
    puts val.to_s 
    #result [3009784, 4901092]
        
      

we created an array that contains 6 objects each value of the object is 0. we spawned 5 threads in each thread we are updating the values of objects inside the array

we expect the output should be [5000000, 5000000] instead we got [3711034,4481783]. Threads will execute in any order we don't have control over that, here val array is accessed by all the threads if multiple threads modify the same object there is a chance for race condition

consider one scenario where val[0] = 100 and val[1] =100 thread t1 executing this line val.map! { |c| c + 1 } and thread t2 executing this line 1000000.times do
If you examine carefully we are doing multiple operations in this step val.map! { |c| c + 1 }

• we are reading the value val[0] from memory
• we are incrementing the value by 1
• we update the new value in the memory

Imagine thread t1 got suspended by CPU before writing 101 to memory and CPU started executing the code. when t2 reads the val[0] from memory it will get 100 instead of 101.
t2 incremented and updated the val[0] and val[1] as 101 and 101 in memory now t2 got suspended and t2 is resumed t2 will start executing where it got paused previously (writing 101 to the memory) it updates the val[0] as 101 in the memory this is called race condition. The data inside the val array is corrupted, to avoid these conditions we can put a lock on the val array.

If any thread puts a lock on a specific section of code remaining threads have to wait until the lock is released. Ruby provides a mutex library to put locks on the code. we can rewrite the above code using the mutex library

        
    val = [0, 0] 
    lock = Mutex.new
    threads = (0...5).map do 
        Thread.new do 
            1000000.times do
                lock.synchronize do
                    val.map! { |c| c + 1 } 
                end 
            end 
        end 
    end 
    threads.each(&:join) 
    puts val.to_s 
    #result [5000000, 5000000]
        
      

Using threads to achieve execution speed is a good idea but we have to keep eye on race conditions and avoid it using locks. And do not create too many threads system can run out of memory ruby provides many libraries to use threads like thread/pool, ruby also provides semaphores which deal with the race conditions by a signaling mechanism

As Uncle Ben said with great power comes great responsibility. Threads are very powerful use them creatively and carefully.

Back To Blogs

---