THE RUBY WAY, Third Edition (2015)

Chapter 13. Threads and Concurrency

He draweth out the thread of his argument finer than the staple of his verbosity.

—William Shakespeare,
Love’s Labours Lost, Act V, Sc. 1

One of the wonders of modern computers is that they appear to be able to do more than one thing at a time. Even back in the days of single-core processes, the lone CPU could switch between its various jobs quickly enough that it appeared to be doing many things at once. With the advent of inexpensive computers with multiple CPUs, that illusion has become reality. Thus, we take it for granted that we can simultaneously download a gem while we surf the Internet and print a document. This concurrency is exposed to programmers in two fundamental forms: processes and threads. In general, a process is a fairly self-sufficient entity, with its own flow of control and its own address space, safely out of reach of other processes (with important exceptions—an operating system must not only protect processes from each other but also provide mechanisms for sharing memory).

Threads are sometimes called lightweight processes. They are a way to achieve concurrency without all the overhead of switching tasks at the operating system level. Although the computing community is not in perfect agreement about the definition of threads, we’ll use the most common definition here.

A thread generally lives inside a process, sharing its address space and open files. The good news about threads is that because they do share so much with their parent process, they are relatively cheap to create. The bad news about threads is that because they share so much with their parent process—and any other threads within that process—they have a tendency to interfere with each other.

Threads are useful in circumstances where separate pieces of code naturally function independently of each other. They are also useful when an application spends much of its time waiting for an event. Often while one thread is waiting, another can be doing useful processing. On the other hand, there are some potential disadvantages in the use of threads. Switching between threads can reduce the speed at which each individual task runs. In some cases, access to a resource is inherently serialized so that threading doesn’t help. Sometimes, the overhead of synchronizing access to resources exceeds the savings due to multithreading.

Threads always incur some kind of performance hit, both in memory and in execution time; it is easy to pass the point of diminishing returns. For these and other reasons, some authorities claim that threaded programming is to be avoided. Indeed, concurrent code can be complex, error prone, and difficult to debug. But with so many CPU cores available in modern computers, the increase in speed for concurrent tasks can be enormous. We leave it to the reader to decide when it is worthwhile to use these techniques.

The difficulties associated with unsynchronized threads are well known. A data structure can be corrupted by threads attempting simultaneous access to the data. Race conditions may occur wherein one thread makes some assumption about what another has done already; these commonly result in “nondeterministic” code that may run differently with each execution. Finally, there is the danger of deadlock, wherein no thread can continue because it is waiting for a resource held by some other thread, which is also blocked. Code written to avoid these problems is referred to asthread-safe code.

Using threads in Ruby presents some additional challenges. The main version of Ruby (MRI, Matz’s Ruby Interpreter) creates threads in the usual way. But—and this is a huge but—it still contains legacy code that is not thread-safe. As a result, it only allows one thread to run at a time. The result is low overhead, but very low concurrency. Multiple threads are only useful in MRI when a program will spend time waiting for I/O.

The story is different if you happen to be using the Rubinius or JRuby interpreters. JRuby is the implementation of Ruby for the Java Virtual Machine, while Rubinius is an experimental interpreter that attempts to implement Ruby using as much Ruby as possible. JRuby’s threads rely on the threading supplied by the underlying Java platform, while Rubinius uses operating system level threads like MRI does. Unlike MRI, both Rubinius and JRuby do not artificially synchronize their threads. This means that in Ruby interpreters other than MRI, threads can run at the same time, using all of the processors available on the machine.

A big part of understanding threads is knowing the synchronization methods that allow you to control access to variables and resources, protect critical sections of code, and avoid deadlock. We will examine each of these techniques and illustrate them with code.

13.1 Creating and Manipulating Threads

The most basic operations on threads include creating a thread, passing information in and out, waiting for a thread, and stopping a thread. We can also obtain lists of threads, check the state of a thread, and check various other information.

13.1.1 Creating Threads

Every program you have ever run had at least one thread associated with it—the initial flow of control that we call the “main” thread. Multithreading happens when we start other threads.

Creating a thread in Ruby is easy. Simply call the new method and attach a block that will be the body of the thread:

thread = Thread.new do
# Statements comprising
# the thread...
end

The method fork is an alias for new, so we could have created our thread by calling Thread.fork instead of Thread.new. No matter which name you use, the value returned is an instance of Thread. You can use the Thread instance to control the thread.

If you want to pass parameters into your thread, you can do so by passing them into Thread.new:

thread2 = Thread.new(99, 100) do |a, b|
# a is a parameter that starts out equal to 99
# b is also a parameter which starts out at 100
end

Thus, the thread block in the preceding example takes two parameters, a and b, which start out as 99 and 100, respectively.

Because threads are built around ordinary code blocks, they can also access variables from the scope in which they were created. Therefore, the following thread can change the values of x and y because those two variables were in scope when we created the block associated with the thread:

x = 1
y = 2

thread3 = Thread.new(99, 100) do |a, b|
# x and y are visible and can be changed!
x = 10
y = 11
end

puts x, y

The danger in doing this sort of thing lies in the question of when. When exactly do the values of x and y change? We can say that they will change sometime after thread3 starts, but that is pretty much all we can say. Once a thread starts, it takes on a life of its own, and unless you do something to synchronize with it, you will have no idea of how fast it will run. Because of this unpredictability, it’s hard to say what the last example will print out. If thread3 finishes very rapidly, we might well see 10 and 11 printed. Conversely, if thread3 is slow off the mark, we might see 1 and 2 printed. There is even a small chance that we might see a 1 followed by an 11 printed if the race between thread3 and the main thread is very close. In real programs, this is exactly the kind of random behavior we would like to avoid.

13.1.2 Accessing Thread-Local Variables

So how do you go about building threads that can share results with the rest of the program without stepping all over variables from outside their scope? Fortunately, Ruby provides us with a special mechanism for this purpose. The trick is that you can treat a thread instance like a hash, setting and getting values by key. This thread-local data can be accessed from both inside and outside of the thread and provide a convenient sharing mechanism between the two. Here is an example of thread-local data in action:

thread = Thread.new do
t = Thread.current
t[:var1] = "This is a string"
t[:var2] = 365
end

sleep 1 # Let the thread spin up

# Access the thread-local data from outside...

x = thread[:var1] # "This is a string"
y = thread[:var2] # 365

has_var2 = thread.key?(:var2) # true
has_var3 = thread.key?(:var3) # false

As you can see from the code, a thread can set its own local data by calling Thread.current to get its own Thread instance and then treating that object like a hash. Thread instances also have a convenient key? instance method that will tell you if a particular key is set. One other nice thing about thread-local data is that it hangs around even after the thread has expired.

Note that thread-local data is not the same as the local variables inside the thread block. The local variable var3 and thread[:var3] may look somewhat alike, but they are definitely not the same:

thread = Thread.new do
t = Thread.current
t["var3"] = "thread local!!"
var3 = "a regular local"
end

sleep 1 # Let the thread spin up

a = thread[:var3] # "thread local!!"

You should also keep in mind that although threads with their thread-local data do act a bit like hashes, they are definitely not the real thing: Threads lack most of the familiar Enumerable methods such as each and find. More significantly, threads are picky about the keys you are allowed to use for the thread-local data. Besides symbols, your only other choice for a thread local key is a string, and if you do use a string, it will get silently converted to a symbol. We can see all of this going on here:

thread = Thread.new do
t = Thread.current
t["started_as_a_string"] = 100
t[:started_as_a_symbol] = 101
end

sleep 1 # Let the thread spin up

a = thread[:started_as_a_string] # 100
b = thread["started_as_a_symbol"] # 101

It’s important to note that while thread-local data can help solve the where problem by giving you a thread-specific place to put data, thread-local data alone doesn’t help with the when problem: Absent some kind of synchronization, you will have no idea when a thread will get around to doing something with its thread-local data. The common case is to “return” thread-local data as the thread finishes executing. No synchronization is needed then because the thread has terminated.

13.1.3 Querying and Changing Thread Status

The Thread class sports a number of useful class methods for managing threads. For example, the list method returns an array of all living threads, whereas the main method returns a reference to the main thread, the one that kicks everything off. And as you have seen, there is also acurrent method that allows a thread to find its own identity.

t1 = Thread.new { sleep 100 }

t2 = Thread.new do
if Thread.current == Thread.main
puts "This is the main thread." # Does NOT print
end
1.upto(1000) { sleep 0.1 }
end

count = Thread.list.size # 3

if Thread.list.include?(Thread.main)
puts "Main thread is alive." # Always prints!
end

if Thread.current == Thread.main
puts "I'm the main thread." # Prints here...
end

The exit, pass, start, stop, and kill methods are used to control the execution of threads, either from inside or outside:

# In the main thread...
Thread.kill(t1) # Kill thread t1 from the previous example
Thread.pass # Give up my timeslice
t3 = Thread.new do
sleep 20
Thread.exit # Exit the current thread
puts "Can't happen!" # Never reached
end

Thread.kill(t2) # Now kill t2

# Now exit the main thread (killing any others)
Thread.exit

Note that there is no instance method stop, so a thread can stop itself but not another thread.

There are also various methods for checking the state of a thread. The instance method alive? will tell whether the thread is still “living” (not exited), and stop? will return true if the thread is either dead or sleeping. Note that alive? and stop? are not really opposites: Both will return true if the thread is sleeping because a sleeping thread is a) still alive and b) not doing anything at the moment:

count = 0
t1 = Thread.new { loop { count += 1 } }
t2 = Thread.new { Thread.stop }

sleep 1 # Let the threads spin up

flags = [t1.alive?, # true
t1.stop?, # false
t2.alive?, # true
t2.stop?] # true

To get a complete picture of where a thread is in its life cycle, use the status method. The possible return values of status are something of a hodgepodge: If the thread is currently running, status will return the string "run"; you will get "sleep" if the thread is stopped, sleeping, or waiting on I/O. If the thread terminated normally, you will get false back from status. Alternatively, status will return nil if the thread died horribly with an exception. You can see all of this in the next example:

t1 = Thread.new { loop {} }
t2 = Thread.new { sleep 5 }
t3 = Thread.new { Thread.stop }
t4 = Thread.new { Thread.exit }
t5 = Thread.new { raise "exception" }

sleep 1 # Let the threads spin up

s1 = t1.status # "run"
s2 = t2.status # "sleep"
s3 = t3.status # "sleep"
s4 = t4.status # false
s5 = t5.status # nil

Threads are also aware of the $SAFE global variable; but when it comes to threads, $SAFE is not quite as global as it seems because each thread effectively has its own. This does seem inconsistent, but we probably shouldn’t complain; this allows us to have threads run with different levels of safety. Because $SAFE isn’t terribly global when it comes to threads, Thread instances have a safe_level method that returns the safe level for that particular thread:

t1 = Thread.new { $SAFE = 1; sleep 5 }
t2 = Thread.new { $SAFE = 3; sleep 5 }
sleep 1
level0 = Thread.main.safe_level # 0
level1 = t1.safe_level # 1
level2 = t2.safe_level # 3

Ruby threads also have a numeric priority: Threads with a higher priority will be scheduled more often. You can look at and change the priority of a thread with the priority accessor:

t1 = Thread.new { loop { sleep 1 } }
t2 = Thread.new { loop { sleep 1 } }
t2.priority = 3 # Set t2 at priority 3
p1 = t1.priority # 0
p2 = t2.priority # 3

The special method pass is used when a thread wants to yield control to the scheduler. A thread that calls pass merely yields its current timeslice; it doesn’t actually stop or go to sleep:

t1 = Thread.new do
Thread.pass
puts "First thread"
end

t2 = Thread.new do
puts "Second thread"
end

sleep 3 # Give the threads a change to run.

In this contrived example, we are more likely to get see the second thread print before the first. If we take out the call to pass, we are a bit more likely to see the first thread—which started first—win the race. Of course, when it comes to unsynchronized threads, there are simply no guarantees. The pass method and thread priorities are there to provide hints to the scheduler, not to keep your threads synchronized.

A thread that is stopped may be awakened by use of the run or wakeup method:

t1 = Thread.new do
Thread.stop
puts "There is an emerald here."
end

t2 = Thread.new do
Thread.stop
puts "You're at Y2."
end

sleep 0.5 # Let the threads start

t1.wakeup
t2.run

sleep 0.5 # Give t2 a chance to run

The difference between these is subtle. The wakeup call will change the state of the thread so that it is runnable but will not schedule it to be run; on the other hand, run will wake up the thread and schedule it for immediate running. When we ran this code, we got the following output:

You're at Y2.
There is an emerald here.

Again, depending on the exact timing and the whims of the thread scheduler, the output could have been reversed. In particular, you should not rely on stop, wakeup, and run to synchronize your threads.

The raise instance method will raise an exception in the thread specified as the receiver. The call does not have to originate within the thread:

factorial1000 = Thread.new do
begin
prod = 1
1.upto(1000) {|n| prod *= n }
puts "1000! = #{prod}"
rescue
# Do nothing...
end
end

sleep 0.01 # Your mileage may vary.
if factorial1000.alive?
factorial1000.raise("Stop!")
puts "Calculation was interrupted!"
else
puts "Calculation was successful."
end

The thread spawned in the preceding example tries to calculate the factorial of 1,000; if it doesn’t succeed within a hundredth of a second, the main thread will get impatient and kill it. Thus, on a relatively slow machine, this code fragment will print the message Calculation was interrupted!.

13.1.4 Achieving a Rendezvous (and Capturing a Return Value)

Sometimes one thread wants to wait for another thread to finish. The instance method join will accomplish this:

t1 = Thread.new { do_something_long }

do_something_brief
t1.join # Don't continue until t1 is done

A very common mistake when doing thread programming is to start some threads and then let the main thread exit. The trouble is that the main thread is special: Ruby terminates the entire process. For example, the following code fragment would never give us its final answer without thejoin at the end:

meaning_of_life = Thread.new do
puts "The answer is..."
sleep 2
puts 42
end

meaning_of_life.join # Wait for the thread to finish

Another useful little join idiom is to wait for all the other living threads to finish:

Thread.list.each { |t| t.join if t != Thread.current }

Note that we have to check that the thread is not the current thread before calling join: It is an error for any thread, even the main thread, to call join on itself.

If two threads try to join the other at the same time, Ruby will detect this deadlock situation and raise an exception:

thr = Thread.new { sleep 1; Thread.main.join }

thr.join # Deadlock results!

As you have seen, every thread has an associated block. Elementary Ruby knowledge tells us that a block can have a return value. This implies that a thread can return a value. The value method will implicitly perform a join operation and wait for the thread to complete; then it will return the value of the last evaluated expression in the thread:

max = 10000
t = Thread.new do
sleep 0.2 # Simulate some deep thought time
42
end

puts "The secret is #{t.value}"

13.1.5 Dealing with Exceptions

What happens if an exception occurs within a thread? Under normal circumstances, an exception inside a thread will not raise in the main thread. Here is an example of a thread raising an exception:

t1 = Thread.new do
puts "Hello"
sleep 1
raise "some exception"
end

t2 = Thread.new do
sleep 2
puts "Hello from the other thread"
end

sleep 3
puts "The End"

That example says hello from both threads, and the main thread announces the end.

Exceptions inside threads are not raised until the join or value method is called on that thread. It is up to some other thread to check on the thread that failed and report the failure. Here is an example of catching an exception raised inside a thread in a safe manner:

t1 = Thread.new do
raise "Oh no!"
puts "This will never print"
end

begin
t1.status # nil, indicating an exception occurred
t1.join
rescue => e
puts "Thread raised #{e.class}: #{e.message}"
end

The example will print the text “Thread raised RuntimeError: Oh no!” It is important to raise errors from threads at a known point so that they can be rescued or re-raised without interrupting critical sections of other threads.

While debugging threaded code, it can sometimes be helpful to use the abort_on_exception flag. When it is set to true (for a single thread or globally on the Thread class), uncaught exceptions will terminate all running threads.

Let’s try that initial example again with abort_on_exception set to true on thread t1:

t1 = Thread.new do
puts "Hello"
sleep 1
raise "some exception"
end

t1.abort_on_exception = true # Watch the fireworks!

t2 = Thread.new do
sleep 2
puts "Hello from the other thread"
end

sleep 3
puts "The End"

In this case, the only output you will see is a single Hello because the uncaught exception in thread t1 will abort both the main thread and t2.

Whereas t1.abort_on_exception only affects the behavior of the one thread, the class-level Thread.abort_on_exception will take down all the threads if any of them raises an uncaught exception.

Note that this option is only suitable for development or debugging because it is equivalent to Thread.list.each(&:kill). The kill method is (ironically) not thread-safe. Only use kill or abort_on_exception for debugging or to terminate threads that are definitely safe to abruptly kill. Aborted threads can hold a lock or be prevented from running clean-up code in an ensure block, which can leave your program in an unrecoverable state.

13.1.6 Using a Thread Group

A thread group is a way of managing threads that are logically related to each other. Normally all threads belong to the Default thread group (which is a class constant). However, you can create thread groups of your own and add threads to them. A thread can only be in one thread group at a time so that when a thread is added to a thread group, it is automatically removed from whatever group it was in previously.

The ThreadGroup.new class method will create a new thread group, and the add instance method will add a thread to the group:

t1 = Thread.new("file1") { sleep(1) }
t2 = Thread.new("file2") { sleep(2) }

threads = ThreadGroup.new
threads.add t1
threads.add t2

The instance method list will return an array of all the threads in the thread group:

# Count living threads in this_group
count = 0
this_group.list.each {|x| count += 1 if x.alive? }
if count < this_group.list.size
puts "Some threads in this_group are not living."
else
puts "All threads in this_group are alive."
end

ThreadGroup instances also feature the oddly named enclose method, which mostly prevents new threads from being added to the group:

tg = ThreadGroup.new
tg.enclose # Enclose the group
tg.add Thread.new {sleep 1} # Boom!

We say “mostly” because any new threads started from a thread already in an enclosed group will still be added to the group. Thread groups also have an enclosed? instance method that will return true if the group has in fact been enclosed.

There is plenty of room for useful methods to be added to ThreadGroup. The following example shows methods to wake up every thread in a group, to wait for all threads to catch up (via join), and to kill all threads in a group:

class ThreadGroup

def wakeup
list.each { |t| t.wakeup }
end

def join
list.each { |t| t.join if t != Thread.current }
end

def kill
list.each { |t| t.kill }
end

end

One thing to keep in mind about thread groups is that as threads die, they are silently removed from their group. So just because you stick threads in a group does not mean they will all be there ten minutes or ten seconds from now.

13.2 Synchronizing Threads

Why is synchronization necessary? It is because the “interleaving” of operations causes variables and other entities to be accessed in ways that are not obvious from reading the code of the individual threads. Two or more threads accessing the same variable may interact with each other in ways that are unforeseen and difficult to debug.

Let’s take this simple piece of code as an example:

def new_value(i)
i + 1
end

x = 0

t1 = Thread.new do
1.upto(1000000) { x = new_value(x) }
end

t2 = Thread.new do
1.upto(1000000) { x = new_value(x) }
end

t1.join
t2.join
puts x

In the example, we start by setting the variable x to zero. Then we start two threads; each thread increments x a million times using the new_value method. Finally, we print out the value of x. Logic tells us that x should be two million when it is printed out. However, sometimes running this code only results in one million!

When this is run on JRuby, the results are even more unexpected: 1143345 on one run, followed by 1077403 on the next and 1158422 on a third. Is this a terrible bug in Ruby?

Not really. Our code assumes that the incrementing of an integer is an atomic (or indivisible) operation. But it isn’t. Consider the logic flow in the following code example. We put thread t1 on the left side and t2 on the right. We put each separate timeslice on a separate line and assume that when we enter this piece of logic, x has the value 123:

t1 t2
__________________________ __________________________

Retrieve value of x (123)
Retrieve value of x (123)
Add one to value (124)
Add one to value (124)
Store 124 back in x
Store 124 back in x

It should be clear that each thread is doing a simple increment from its own point of view. But it can also been seen that, in this case, x is still 124 after having been incremented by both threads. We deliberately made things worse in our example by introducing the call to new_value, which increases the interval between retrieving the value of x and storing the incremented value. Even the relatively minuscule delay of a single function call is enough to dramatically decrease the number of times the value is incremented correctly.

MRI’s ability to sometimes produce the correct result might lead a casual observer to think this code is thread-safe. The problem is hidden as a side effect of MRI’s GIL, or Global Interpreter Lock, which ensures that only one thread can run at a time. As you just saw, even with the GIL, MRI suffers from the same synchronization problem and can still produce the wrong result.

The worse news is that this is only the simplest of synchronization problems. Complex multithreaded programs can be full of subtle “works most of the time” bugs, and the best way to handle these issues is still a hot topic of study by computer scientists and mathematicians.

13.2.1 Performing Simple Synchronization

The simplest form of synchronization is to use Thread.exclusive. The Thread.exclusive method defines a critical section of code: Whenever one thread is in a critical section, no other threads will run.

Using Thread.exclusive is easy: You simply pass in a block. Ruby will ensure that no other thread is running while the code in the block is executed. In the following code, we revisit the previous example and use the Thread.exclusive method to define the critical section and protect the sensitive parts of the code:

def new_value(i)
i + 1
end

x = 0

t1 = Thread.new do
1.upto(1000000) do
Thread.exclusive { x = new_value(x) }
end
end

t2 = Thread.new do
1.upto(1000000) do
Thread.exclusive { x = new_value(x) }
end
end

t1.join
t2.join
puts x

Although we haven’t changed the actual code very much, we have changed the flow of execution quite a bit. The calls to Thread.exclusive prevent our threads from stepping all over each other:

t1 t2
__________________________ __________________________

Retrieve value of x (123)
Add one to value (124)
Store 124 back in x
Retrieve value of x (124)
Add one to value (125)
Store 125 back in x

In practice, using Thread.exclusive presents a number of problems, the key one being just how expansive its effects are. Using Thread.exclusive means that you are blocking almost all other threads, including innocent ones that will never touch any of your precious data.

The almost touches on another problem: Although Thread.exclusive is expansive, it is not completely airtight. There are circumstances under which another thread can run even while a Thread.exclusive block is under way. For example, if you start a second thread inside your exclusive block, that thread will run.

For these reasons, Thread.exclusive is at its best in simple examples like the one in this section. Fortunately, Ruby has a number of other, more flexible and easily targeted thread-synchronization tools.

13.2.2 Synchronizing Access with a Mutex

One such tool is the mutex (short for mutual exclusion). To see Ruby’s mutex in action, let’s rework our last counting example to use one:

require 'thread'

def new_value(i)
i + 1
end

x = 0
mutex = Mutex.new

t1 = Thread.new do
1.upto(1000000) do
mutex.lock
x = new_value(x)
mutex.unlock
end
end

t2 = Thread.new do
1.upto(1000000) do
mutex.lock
x = new_value(x)
mutex.unlock
end
end

t1.join
t2.join
puts x

Instances of the Mutex class provide a sort of privately scoped synchronization: Mutex ensures that only one thread at a time can call lock. If two threads happen to call lock at about the same time, one of the threads will be suspended until the lucky thread—the one that got the lock—calls unlock. Because any given mutex instance only affects the threads that are trying to call lock for that instance, we can have our synchronization without making all but one of our threads come to a halt.

In addition to lock, the Mutex class also has a try_lock method. The try_lock method behaves just like lock, except that it doesn’t block: If another thread already has the lock, try_lock will return false immediately:

require 'thread'

mutex = Mutex.new
t1 = Thread.new do
mutex.lock
sleep 10
end

sleep 1

t2 = Thread.new do
if mutex.try_lock
puts "Locked it"
else
puts "Could not lock" # Prints immediately
end
end

This feature is useful any time a thread doesn’t want to be blocked. Mutex instances also have a synchronize method that takes a block:

x = 0
mutex = Mutex.new

t1 = Thread.new do
1.upto(1000000) do
mutex.synchronize { x = new_value(x) }
end
end

Finally, there is also a mutex_m library defining a Mutex_m module, which can be mixed into a class (or used to extend an object). Any such extended object has the mutex methods so that the object itself can be treated as a mutex:

require 'mutex_m'

class MyClass
include Mutex_m

# Now any MyClass object can call
# lock, unlock, synchronize, ...
# or external objects can invoke
# these methods on a MyClass object.
end

13.2.3 Using the Built-in Queue Classes

The thread library thread.rb has a couple of queueing classes that will be useful from time to time. The class Queue is a thread-aware queue that synchronizes access to the ends of the queue; that is, different threads can share the same queue without interfering with each other. The classSizedQueue is essentially the same, except that it allows a limit to be placed on the number of elements a given queue instance can hold.

Queue and SizedQueue have much the same set of methods available because SizedQueue actually inherits from Queue. The SizedQueue class also has the accessor max, used to get or set the maximum size of the queue:

buff = SizedQueue.new(25)
upper1 = buff.max # 25
# Now raise it...
buff.max = 50
upper2 = buff.max # 50

Listing 13.1 is a simple producer-consumer illustration. The consumer is delayed slightly longer on average (through a longer sleep) so that the items will “pile up” a little.

Listing 13.1 The Producer-Consumer Problem