Working With Multithreaded Ruby Part II
Stanislav Kozlovski
Posted on October 16, 2017
We're back at it with another edition of Multithreaded Ruby where we'll continue to dive into concurrency using our beloved language!
Today, I'm going to introduce you to a famous multi-process synchronization problem called the Producer-Consumer problem and we're going to look at Ruby's ConditionVariable class.
Back to Deadlock
A paragraph into the new article and we're at deadlocks again? Well yes, they're pretty prevalent and we did not actually touch on a solution to the problem last time.
Let's bring back the deadlock example we used in Part I, modified just a tiny bit.
require 'thwait'
item_accessories = {}
item = {}
item_acc_lock = Mutex.new
item_lock = Mutex.new
a = Thread.new {
item_acc_lock.synchronize {
sleep 1 # pretend to work on item_accessories
item_lock.synchronize {
# pretend to work on item
sleep 1
puts 'Worked on accessories, then on item'
}
}
}
b = Thread.new {
item_lock.synchronize {
sleep 1 # pretend to work on item
item_acc_lock.synchronize {
# pretend to work on item_accessories
sleep 1
puts 'Worked on item, then on accessories'
}
}
}
ThWait.all_waits(a, b)
> enether$ ruby item_worker.rb
/Users/enether/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/thwait.rb:112:in `pop': No live threads left. Deadlock? (fatal)
No surprise here, thread a obviously takes a hold of item_acc_lock, thread b takes a hold of item_lock and each of them waits for the opposite lock in an endless loop. So how could we avoid this?
What if we had a way to temporarily release one of the locks at a specific point in our program where we could afford doing so? That way, the other thread could take the lock, do its thing and return it back for the original one to finish its work.
Enter ConditionVariable
ConditionVariable is a Ruby class which lets you block a thread until another thread signals it OK to continue. It is a way to say - "I'm waiting for a lock and I can give up mine at this exact time". It is an ideal way to synchronize our a and b threads here:
require 'thwait'
item_accessories = {}
item = {}
item_acc_lock = Mutex.new
item_lock = Mutex.new
cv = ConditionVariable.new
a = Thread.new {
item_acc_lock.synchronize {
sleep 1 # pretend to work on item_accessories
# At this point, we've just finished work on item_accessories and we're at a window where we
# might not care if item_accessories changes. So: let somebody else take it and give it back
cv.wait(item_acc_lock) # Temporarily sleeps the thread and releases the lock
puts 'Gained back access to item_acc_lock' # on this line, item_acc_lock is re-acquired
item_lock.synchronize {
# pretend to work on item
sleep 1
puts 'Worked on accessories, then on item'
}
}
}
b = Thread.new {
item_lock.synchronize {
sleep 1 # pretend to work on item
item_acc_lock.synchronize {
# pretend to work on item_accessories
sleep 1
puts 'Worked on item, then on accessories'
}
cv.signal
puts "I'm still working, but I'm finished with item_acc_lock"
}
}
ThWait.all_waits(a, b)
> enether$ ruby synchronized_item_worker.rb
Worked on item, then on accessories
I'm still working, but I'm finished with item_acc_lock
Gained back access to item_acc_lock
Worked on accessories, then on item
What we achieved here is a sort of synchronization: we can now be sure that one b thread will always reach its cv.signal line before an a thread starts working on item_accessories.
Here is a picture visualizing the process:
You might want to open this in another tab - High-Resolution
It is worth noting that the ConditionVariable#signal method will only wake up one thread which is waiting for the variable. This means that if we have two threads waiting on a ConditionVariable and its signal method is called only once, the thread that does not get called will end up waiting forever for the ConditionVariable, resulting in a deadlock
require 'thwait'
lock = Mutex.new
cv = ConditionVariable.new
threads = []
2.times do
threads << Thread.new {
lock.synchronize { cv.wait(lock) }
}
end
threads << Thread.new {
lock.synchronize { sleep 1 }
cv.signal
}
ThWait.all_waits(*threads)
> enether$ ruby cv_pitfall.rb
/Users/enether/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/thwait.rb:112:in `pop': No live threads left. Deadlock? (fatal)
In such a scenario, you need to either call signal as many times as there are waits or use another method - ConditionVariable#broadcast, which will wake up every thread that is waiting on the condition variable.
Producer-Consumer
The producer-consumer problem consists of at minimum two threads, one representing a producer and one representing a consumer.
- Producer - Sole job is to create an item and put it into the buffer
- Consumer - Sole job is to take the item from the buffer and process it
Here is a sample implementation in Ruby, where the tasks array acts as the buffer with a fictional limitation of having at most 2 items in it at once:
require 'thwait'
threads = []
tasks = []
mutex = Mutex.new
# producer
2.times do
threads << Thread.new do
loop do
mutex.synchronize do
if tasks.length < 2
tasks << "Task :)"
end
end
end
end
end
# consumer
5.times do
threads << Thread.new do
loop do
task = nil
mutex.synchronize do
if tasks.length != 0
task = tasks.shift
end
end
unless task.nil?
100000.times do
# Simulating task execution's CPU work
# also doing it outside the mutex so we don't block the tasks array (other producer might want to take a task as well)
end
end
end
end
end
ThWait.all_waits(threads)
Producer-Consumer problem
As the name implies, something is not quite right with the code above. Finding problems in concurrent code is hard, so I'm going to give you a couple of minutes to figure out what is wrong.
...
...
...
Okay, if you managed to figure it out - great, if not - don't fret, multithreaded programming is unintuitive.
The problem with the code above is that it wastes time. You see, as we can't control when and to which thread the OS switches to, there is the possibility that we leave our consumer thread and enter the producer's when there is no reason to.
Imagine all our consumer threads are currently executing a task and our tasks array is full (has two elements). If the OS decides to do a context switch and gives control to a producer thread it would only waste time. Since the tasks array would be full, the producer would loop only to check that the array is full and not do anything else, only managing to take precious CPU time from our consumer threads.
Let's track exactly how much useless iterations this thing does:
require 'thwait'
threads = []
tasks = []
mutex = Mutex.new
to_exit = false
times_tasks_added = 0
times_time_wasted = 0
executed_tasks = 0
# consumer
2.times do
threads << Thread.new do
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
mutex.synchronize do
if tasks.length < 2
tasks << "Task :)"
times_tasks_added += 1
else
# time here is absolutely wasted
times_time_wasted += 1
end
end
end
end
end
# producer
5.times do
threads << Thread.new do
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
task = nil
mutex.synchronize do
if tasks.length != 0
task = tasks.shift
end
end
unless task.nil?
100000.times do
# Simulating CPU work
# also doing it outside the mutex so we don't block the tasks array (other producer might want to take a task as well)
end
executed_tasks += 1
if executed_tasks >= 100 # don't loop forever
to_exit = true
end
end
end
end
end
ThWait.all_waits(threads)
puts "Total tasks added: #{times_tasks_added}"
puts "Total times we branched out into the useless else statement: #{times_time_wasted}"
And here are the results:
> enether$ ruby squander_of_time.rb
Total tasks added: 102
Total times we branched out into the useless else statement: 1633
> enether$ ruby squander_of_time.rb
Total tasks added: 102
Total times we branched out into the useless else statement: 848282
> enether$ ruby squander_of_time.rb
Total tasks added: 102
Total times we branched out into the useless else statement: 356418
We know that thread context-switching is non-deterministic and these results further prove it. Sometimes we do as little as 1633 useless executions of the else branch and some - as much as 848k, 8316 times more than we need!
This is bad because it will cause your program to run slower at some times and behave seemingly normal in others.
It's good to note that I personally found it hard to figure out the problem in this code even though it's specifically made to illustrate it. Imagine how hard it would be to spot such a thing in an established codebase!
This slow-down is not acceptable, so let's fix it. Thinking the problem through, our problem seems to boil down to having a producer thread wake up when it doesn't make sense.
What would be perfect is if we had the ability to somehow control when we resume the producer thread - specifically when a task is removed from the tasks buffer so we're sure there's room to add another one.
ConditionVariable to the rescue!
The fix is simple: We're just going to put a condition variable which is going to give up the mutex lock whenever we detect that we do not need to continue looping in the producer. We're also going to need to tell the producer he can resume when we have an empty spot in the tasks buffer.
require 'thwait'
threads = []
tasks = []
mutex = Mutex.new
to_exit = false
times_tasks_added = 0
times_time_wasted = 0
executed_tasks = 0
cv = ConditionVariable.new
# consumer
2.times do
threads << Thread.new do
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
mutex.synchronize do
if tasks.length < 2
tasks << "Task :)"
times_tasks_added += 1
else
times_time_wasted += 1
cv.wait(mutex) # no need to continue looping in such a case, only continue after it makes sense
end
end
end
end
end
# producer
5.times do
threads << Thread.new do
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
task = nil
mutex.synchronize do
if tasks.length != 0
task = tasks.shift
cv.signal # one new task can now be added
end
end
unless task.nil?
100000.times do
# Simulating CPU work
# also doing it outside the mutex so we don't block te tasks array (other producer might want to take a task as well)
end
executed_tasks += 1
if executed_tasks >= 100 # don't loop forever
to_exit = true
end
end
end
end
end
ThWait.all_waits(threads)
puts "Total tasks added: #{times_tasks_added}"
puts "Total times we branched out into the useless else statement: #{times_time_wasted}"
> enether$ ruby saver_of_time.rb
Total tasks added: 101
Total times we branched out into the useless else statement: 50
> enether$ ruby saver_of_time.rb
Total tasks added: 100
Total times we branched out into the useless else statement: 45
> enether$ ruby saver_of_time.rb
Total tasks added: 100
Total times we branched out into the useless else statement: 42
Woo, performance!
In reality, it's worth noting that the previous example and this one actually run in about the same time. 400k useless iterations sound like a lot but our computers are fast enough to not let us notice this inefficiency. Regardless, I hope this example managed to clearly illustrate the problem.
Further optimization
Do we even need to enter the else branch at all? Could we not put cv.wait inside the block which adds the tasks and have it call wait when the buffer is full? We can and that way it should never enter the else block, as it would only be resumed to add a task and sleep if the buffer is full.
# ...
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
mutex.synchronize do
if tasks.length < 2
tasks << "Task :)"
times_tasks_added += 1
if tasks.length >= 2
cv.wait(mutex) # no need to continue looping in such a case, only continue after it makes sense
end
else
times_time_wasted += 1
end
end
end
# ...
> enether$ ruby no_time_wasted.rb
Total tasks added: 100.
Total times we branched out into the useless else statement: 16
> enether$ ruby no_time_wasted.rb
Total tasks added: 102
Total times we branched out into the useless else statement: 13
> enether$ ruby no_time_wasted.rb
Total tasks added: 101
Total times we branched out into the useless else statement: 372021
What the hell? We still got entered the else block and we even got back to the previous levels of needless execution!
Concurrent programming is hard. We're using two producer threads here and when one fills up the tasks array it frees the mutex. The other producer thread seems to get resumed (remember we free the mutex only when tasks is full) and enters the else branch as the tasks buffer is full.
You might want to open this in another tab - High-Resolution
Okay, well the simplest thing to do is put a wait back where we had one. This should limit the useless calls as much as possible:
# ...
loop do
Thread.kill(Thread.current) if to_exit # a way to stop execution
mutex.synchronize do
if tasks.length < 2
tasks << "Task :)"
times_tasks_added += 1
if tasks.length >= 2
cv.wait(mutex)
end
else
times_time_wasted += 1
cv.wait(mutex)
end
end
end
# ...
> enether$ ruby no_time_wasted_fixed.rb
Total tasks added: 101
Total times we branched out into the useless else statement: 5
> enether$ ruby no_time_wasted_fixed.rb
Total tasks added: 101
Total times we branched out into the useless else statement: 8
> enether$ ruby no_time_wasted_fixed.rb
Total tasks added: 101
Total times we branched out into the useless else statement: 3
Well I'm afraid this is as much as we can do with the ConditionVariable. The reason we still enter the else block a couple of times is most likely the one depicted in the image above.
Although there is one other possibility:
Spurious Wakeups
A spurious wakeup is when a ConditionVariable gets woken up without getting signaled to. This might sound stupid but it makes sense, since it seems to boost performance in some cases. According to David R. Butenhof's Programming with POSIX Threads (ISBN 0-201-63392-2): "Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations.".
They also enforce robust multithreaded code, essentially enforcing you to take care of such cases. This is why it is strongly recommended that you always put your ConditionVariables inside a loop which always checks the appropriate condition (as we do with if tasks.length < 2).
Here is an interesting discussion on the topic: comp.programming.threads
I personally could not identify when a producer thread was woken up spuriously or simply got scheduled when a previous producer went to sleep. I did dig through the MRI code to verify that cv.wait is vulnerable to spurious wakeups.
Here is the way it gets called - rb_condvar_wait -> do_sleep -> mutex_sleep -> rb_mutex_sleep -> rb_mutex_sleep_forever -> rb_thread_sleep_deadly_allow_spurious_wakeup -> sleep_forever
It seems to boil down to calling the sleep_forever function which calls native_sleep in a loop. After the code exits from the sleep, Ruby checks if the thread was woken up on purpose (in RUBY_VM_CHECK_INTS_BLOCKING(th)) and schedules it to be interrupted if so. Since ours isn't, it likely enters the if (!spurious_check) block and breaks the loop, effectively stopping the sleep.
Summary
We touched on a couple of important topics in multithreaded programming.
We learned about the precious ConditionVariable class and more specifically how it allows you to pause threads at will and schedule a resume when you decide to.
-
ConditionVariable#wait(mutex)- puts the current thread to sleep, releases the given mutex for the time being and gets resumed strictly after a signal -
ConditionVariable#signal- allows one thread that holds the given condition variable that to resume -
ConditionVariable#broadcast- allows all threads that hold the given condition variable to resume
We dabbled into the producer-consumer problem, trying to optimize it on our own and further explored concurrency problems and in the end learned about spurious wakeups.
Posted on October 16, 2017
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.